DDC-2179: Transactions should sent in group not chunked #2746

Closed
opened 2026-01-22 14:02:15 +01:00 by admin · 4 comments
Owner

Originally created by @doctrinebot on GitHub (Nov 29, 2012).

Originally assigned to: @Ocramius on GitHub.

Jira issue originally created by user dlsniper:

In UnitOfWork::commit() it seems that a transaction is done like this:

  • will send separate queries for transaction start
  • compute the queries/send them to the db driver
  • execute the commit statement
  • optionally execute rollback

The question would be, should my webserver have some issues with resources, wouldn't this part of the code be a pain for the DB?

I don't know how mysql, for example, handles sending the transaction in chunks as opposed to sending it in 2/3 statements ( begin ops and commit / revert in case of failure) or in mySQL,l the transaction is evaluated on COMMIT statement only?

If my assumption about how MySQL works, locking everything as soon as the statement is on the server, then shouldn't Doctrine use a internal buffer for sending transactions to the DB driver in order to avoid all sorts of problems that appear in high concurency scenarios?

Best regards.

Originally created by @doctrinebot on GitHub (Nov 29, 2012). Originally assigned to: @Ocramius on GitHub. Jira issue originally created by user dlsniper: In UnitOfWork::commit() it seems that a transaction is done like this: - will send separate queries for transaction start - compute the queries/send them to the db driver - execute the commit statement - optionally execute rollback The question would be, should my webserver have some issues with resources, wouldn't this part of the code be a pain for the DB? I don't know how mysql, for example, handles sending the transaction in chunks as opposed to sending it in 2/3 statements ( begin <ins> ops and commit / </ins> revert in case of failure) or in mySQL,l the transaction is evaluated on COMMIT statement only? If my assumption about how MySQL works, locking everything as soon as the statement is on the server, then shouldn't Doctrine use a internal buffer for sending transactions to the DB driver in order to avoid all sorts of problems that appear in high concurency scenarios? Best regards.
admin added the Bug label 2026-01-22 14:02:15 +01:00
admin closed this issue 2026-01-22 14:02:16 +01:00
Author
Owner

@doctrinebot commented on GitHub (Nov 30, 2012):

Comment created by @ocramius:

Invalid IMO. This is an over-complication that (in such high load scenarios) is handled by clustering/load balancing. Not a problem of the ORM, since smashing all statements together will just make it impossible to trap any problems.

@doctrinebot commented on GitHub (Nov 30, 2012): Comment created by @ocramius: Invalid IMO. This is an over-complication that (in such high load scenarios) is handled by clustering/load balancing. Not a problem of the ORM, since smashing all statements together will just make it impossible to trap any problems.
Author
Owner

@doctrinebot commented on GitHub (Nov 30, 2012):

Comment created by @ocramius:

This performance improvement has been discussed directly on IRC.

The original problem is related to deadlocks and small transactions, which is not anyway solved by this issue.

Otherwise, this improvement requires a PoC that shows that it is possible to have exceptions still showing the query that caused the failure.

@doctrinebot commented on GitHub (Nov 30, 2012): Comment created by @ocramius: This performance improvement has been discussed directly on IRC. The original problem is related to deadlocks and small transactions, which is not anyway solved by this issue. Otherwise, this improvement requires a PoC that shows that it is possible to have exceptions still showing the query that caused the failure.
Author
Owner

@doctrinebot commented on GitHub (Nov 30, 2012):

Issue was closed with resolution "Invalid"

@doctrinebot commented on GitHub (Nov 30, 2012): Issue was closed with resolution "Invalid"
Author
Owner

@doctrinebot commented on GitHub (Nov 30, 2012):

Comment created by @ocramius:

Sorry, was unclear. I basically mean that any approach squashing the queries into a single chunk sent to the DB should also allow us to get computed insert IDs and eventual exceptions should bubble up with the query that caused them.

@doctrinebot commented on GitHub (Nov 30, 2012): Comment created by @ocramius: Sorry, was unclear. I basically mean that any approach squashing the queries into a single chunk sent to the DB should also allow us to get computed insert IDs and eventual exceptions should bubble up with the query that caused them.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#2746