Skip to content

Possible problems after release next versions of Doctrine DBAL in messenger transaction middleware. #53642

@ZhukV

Description

@ZhukV

Description

By default, doctrine not use savepoints, and if developer open transaction in opened transaction, doctrine dbal nothing to do (developer can change it, and work with savepoints).

It's very powerful, because I as developer can use TransactionMiddleware on message bus, and not think about flush entity managers and easy to use locks mechanism on db.

And, we must understand, that developer can execute message inside another message handler (nested calls). In this case, on TransactionMiddelware always calls beginTransaction, but doctrine/dbal control nested calls and don't execute any code on beginTransaction if transaction already opened (this setting can be configured, but only now).

Now, Doctrine/DBAL trigger deprecations if developer try begin new transaction inside opened transaction and will be use savepoints. (https://github.com/doctrine/dbal/pull/5383/files).

After next update of Doctrine/DBAL, developer can have any problems, because they can use nested message calls, and doctrine open multiple savepoints, which can be difficult for a developer (previosly doctrine/dbal open only root transaction, without savepoints).

I try to ask question doctrine/dbal#6272 and describe possible problem, but not any response.

As result, to avoid possible problems, control nested transaction can be implemented on TransactionalMiddelware, and add possible to configure it for developer.

P.S. I understand, control nested calls inside TransactionMiddleware bad idea, but I doubt that doctrine/dbal will do anything to solve this problem.

Example

No response

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions