Transactions and Concurrency Documentation Lacks Descriptions of Rollback #5057

New Issue

admin · 2026-01-22T14:57:25+01:00

admin commented

2026-01-22 14:57:25 +01:00

Originally created by @edhgoose on GitHub (Mar 19, 2016).

Hi,

Apologies if this issue is somewhat speculative, but I've been working with Symfony transactions and surprised that (as far as I can tell, please correct me if I'm wrong) that the documentation available is limited to http://doctrine-orm.readthedocs.org/projects/doctrine-orm/en/latest/reference/transactions-and-concurrency.html.

There seems to be a big gap regarding the failure of transactions.

In the case where for instance my application hits deadlock or some sort of issue (a problem I am currently facing), there appears to be very little that can be done and very little consensus regarding how to handle the rollback.

If it provides context, I have a request where a User is completing an action and as a result I want to persist a small number of objects to the Database (MySQL in this context). I don't really want to fail it and ask them to try again in the case where a deadlock has occurred - I'd like to at least try again a couple of times before making the user repeat their action.

I've seen a few examples where people suggest that the ManagerRegistry (https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Persistence/ManagerRegistry.php) should be passed into services instead of the EntityManager and that the manager can be reset then you continue.

I've also seen this SO answer which manages to provide several completely different answers with very little context as to why/how they work and/or whether they should work consistently and/or whether they are the 'correct' way to handle transactions. It's also a bit of an old answer so I'm not sure if the recommended approach has changed.

I'd like to see the details of the transaction documentation expanded to cover the correct way(s) and reasons you may approach handling transaction failure.

I'd be happy to write the documentation if someone can help provide the scaffold for it.

In particular, I'd like to see:

The correct way to begin (e.g. should you pass in the ManagerRegistry instead of the EntityManager)
Approaches to handling failure
How this affects other parts of your system (e.g. if I reset the entity manager in one Symfony service, is it reset in all other services using an entity manager?)
Side effects (if any) of the approaches.

Cheers,
Ed

Originally created by @edhgoose on GitHub (Mar 19, 2016). Hi, Apologies if this issue is somewhat speculative, but I've been working with Symfony transactions and surprised that (as far as I can tell, please correct me if I'm wrong) that the documentation available is limited to http://doctrine-orm.readthedocs.org/projects/doctrine-orm/en/latest/reference/transactions-and-concurrency.html. There seems to be a big gap regarding the _failure_ of transactions. In the case where for instance my application hits deadlock or some sort of issue (a problem I am currently facing), there appears to be very little that can be done and very little consensus regarding how to handle the rollback. If it provides context, I have a request where a User is completing an action and as a result I want to persist a small number of objects to the Database (MySQL in this context). I don't really want to fail it and ask them to try again in the case where a deadlock has occurred - I'd like to at least try again a couple of times before making the user repeat their action. I've seen a few examples where people suggest that the ManagerRegistry (https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Persistence/ManagerRegistry.php) should be passed into services instead of the EntityManager and that the manager can be reset then you continue. I've also seen [this](http://stackoverflow.com/questions/14258591/the-entitymanager-is-closed) SO answer which manages to provide several completely different answers with very little context as to why/how they work and/or whether they should work consistently and/or whether they are the 'correct' way to handle transactions. It's also a bit of an old answer so I'm not sure if the recommended approach has changed. I'd like to see the details of the transaction documentation expanded to cover the correct way(s) and reasons you may approach handling transaction failure. I'd be happy to write the documentation if someone can help provide the scaffold for it. In particular, I'd like to see: - The correct way to begin (e.g. should you pass in the ManagerRegistry instead of the EntityManager) - Approaches to handling failure - How this affects other parts of your system (e.g. if I reset the entity manager in one Symfony service, is it reset in all other services using an entity manager?) - Side effects (if any) of the approaches. Cheers, Ed

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5057