I was also thinking about introducing a similar functionality, not exactly nested transaction but just a way to prevent $db->commit and $db->rollback from doing enything. Akshay(my GSoC) wanted to have his extension code transaction safe, but there was just no way of doing it without tinkering with the core. So it's true in core there is (as it should be) no actual need for transaction nesting, but there are extensions that could use some tx safety.
The simplest way i can think of how this could be done is changing $db->mTrxLevel from a flag to a counter and start using savepoints (doable in Mysql, PG and Oracle, don't know for other DBs). So only the first mTrxLevel would do actual commit or blank rollback (maybe add an optional parameter to calls to override), on higher levels you would just skip on commit and rollback to savepoint on rollback call.
LP, Jure
On 08/24/2012 01:13 AM, Jeroen De Dauw wrote:
I'm not saying we have any such code, I'm asking what to do when one wants to introduce such code. It's entirely feasible some new functionality requires serializable transactions, so we might want to keep that into consideration.
Sent from my Android phone. On 24 Aug 2012 00:30, "Platonides" Platonides@gmail.com wrote:
On 23/08/12 23:54, Jeroen De Dauw wrote:
Hey,
One concern I have with big transcations that have lots of stuff in them
is
that some code might get called in which needs to run in a transaction
with
a higher isolation level then the current one. For MySQLs InnoDB the default is repeatable read, so if you have code that requires serializability and gets called during that transaction, you're basically fucked. Or am I missing something?
Cheers
I don't think we have any code requiring a different transaction isolation.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l