Kristian Nielsen
Hm, I now realise a problem with this approach :-/
The problem is with MyISAM tables, or other tables that use table-level locking instead of row-level locking.
If transactions T1 and T2 both update the same table mytable, then it can happen that T2 runs first and gets a table lock on table mytable. T1 then has to wait for T2 to commit, after which the table lock is released. But T2 will never commit, it will wait for T1 to commit first with my patch. Thus we have a deadlock.
Hm, no, actually I was wrong. There seems to be no deadlock with MyISAM tables. I am not sure yet, but I think what is happening is that MyISAM table locks are released during the "statement" commit. But the wait-for-prior-commit occurs only at the "transaction" commit, which happens after. This is as it should be, and it means that T2 can release table locks before waiting for T1, so T1 can complete and signal T2 to continue. So no deadlock. So this looks like it is not a problem after all. Of course, with MyISAM we will not really get ordered-commit semantics. It is not possible with MyISAM to run statements in parallel out-of-order without also seeing the updates out-of-order; this requires a transactional MVCC engine. But this is expected with MyISAM. So the problem I see in the test rpl_row_001 must be something else, still looking... - Kristian.