http://www.doctrine-project.org/jira This file is an XML representation of an issue en-us 5.2.7 850 21-02-2013 http://www.doctrine-project.org/jira/browse/DDC-2179 Doctrine 2 - ORM <p>In UnitOfWork::commit() it seems that a transaction is done like this:</p> <ul class="alternate" type="square"> <li>will send separate queries for transaction start</li> <li>compute the queries/send them to the db driver</li> <li>execute the commit statement</li> <li>optionally execute rollback</li> </ul> <p>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?</p> <p>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?</p> <p>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?</p> <p>Best regards.</p> MySQL 5.5 / Percona DDC-2179

Transactions should sent in group not chunked

Bug Critical Closed Invalid All Marco Pivetta Florin Patan unitofwork Thu, 29 Nov 2012 22:16:37 +0000 Fri, 30 Nov 2012 14:31:16 +0000 Fri, 30 Nov 2012 14:28:10 +0000 2.2 2.3 Git Master Mapping Drivers 0 2 <p>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.</p> <p>This performance improvement has been discussed directly on IRC.</p> <p>The original problem is related to deadlocks and small transactions, which is not anyway solved by this issue.</p> <p>Otherwise, this improvement requires a PoC that shows that it is possible to have exceptions still showing the query that caused the failure.</p> <p>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.</p>