maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:

> 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.