I'm aware that ideally, you should write your application in a way that would prevent deadlocks entirely.
However, the world is not ideal, and our application seems awfully attracted to causing deadlocks. As a fallback, there is the concept of retrying the transaction as a deadlock occurs. We have tried to implement such mechanism, but experienced trouble with Doctrine and nested transactions. Here is what happens: - Deadlock occurs; MySQL rolls back the transaction. - An exception is thrown. - Doctrine catches the exception and attempts another rollback. - This happens to be a rollback to a savepoint. - But the savepoints have already been rolled back previously by MySQL. - Therefore, an exception is thrown that the savepoint was not found. - Now, we are unable to determine whether a rollback has previously occurred. Even if this savepoint issue was resolved or we were to forego the use of nested transactions, a problem still remains: The DBAL connection thinks that we are still inside a transaction, although MySQL already canceled it. Therefore, the internal status of the DBAL connection is wrong, which seems to render it unusable. >From here, we found no way to retry the transaction, save for creating a new connection or modifying private properties using reflection... Am I missing something here? Is there a way to cleanly deal with deadlocks if they are unavoidable? (We have experienced this problem in Doctrine 2.3 but are currently switching to 2.5, so if there's any hidden improvements regarding this issue, this might also help) -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
