On 23.08.2012 22:49, Brion Vibber wrote:

Well, the main reason is probably that MySQL doesn't support nested transactions... trying to simulate them with a counter sounds fragile, as a single rollback would roll back the entire transaction "tree", not just the last nested one you started (or else do nothing if you just decrement the counter, also possibly dangerous if you expected the rollback to work).

To me it seems correct and safe to assume that a ROLLBACK will cause all open transactions to fail. I don't see any problem with handling things this way. Am I missing something? Was there any *concrete* problem that caused this feature to be removed?

On 23.08.2012 23:21, Brion Vibber wrote:

On Thu, Aug 23, 2012 at 2:02 PM, Evan Priestley epriestley@phacility.comwrote:

...

We solve this in Phabricator by using BEGIN (depth 0) or SAVEPOINT (depth 1+) when incrementing the counter, ROLLBACK TO SAVEPOINT (depth 1+) or ROLLBACK (depth 0) when decrementing it after a failure, and nothing (depth

1. or COMMIT (depth 0) when decrementing it after a success. Our experience

with transaction stacks has generally been good (no real surprises, doesn't feel magical, significantly reduces the complexity of transactional code), although we don't support anything but MySQL.

Oooh, nice! Hadn't come across SAVEPOINT before.

http://dev.mysql.com/doc/refman/5.0/en/savepoint.html

Hm... that'S a 404 for me. For some reason, this is missing in the 5.0 manual, even though it exists in 4.1 and 5.1:

http://dev.mysql.com/doc/refman/5.1/en/savepoint.html

Anyway, this seems like a neat solution if it is handled automatically by begin(), rollback() and commit(), so the calling code doesn't have to be aware of the current transaction level.

I'm tempted to implement this. Any objections?

-- daniel

PS: