maria-developers team mailing list archive

[Michael Widenius <monty@xxxxxxxxxxxx>]

Hi!

>>>>> "Kristian" == Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:

Kristian> Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx> writes:
>> The patch makes later transactions wait for earlier transactions to commit
>> before committing themselves.

Kristian> Hm, I now realise a problem with this approach :-/

Kristian> The problem is with MyISAM tables, or other tables that use table-level
Kristian> locking instead of row-level locking.

Kristian> If transactions T1 and T2 both update the same table mytable, then it can
Kristian> happen that T2 runs first and gets a table lock on table mytable. T1 then has
Kristian> to wait for T2 to commit, after which the table lock is released. But T2 will
Kristian> never commit, it will wait for T1 to commit first with my patch. Thus we have
Kristian> a deadlock.

The simplest way to solve things like this is that for transactions that
are using table handlers with table level locking, you start the
transactions also in order;  As soon as the table locks are taken
(after open_-and-lock-tables) you can start the next transaction.

Kristian> One way to fix this could be to extend your algorithm for detecting conflicts
Kristian> between different transactions. If some table T uses table-level locking, then
Kristian> put into the hash just the table name, without any primary key values. Then
Kristian> any two such transactions will be considered conflicting, and we avoid the
Kristian> deadlock. No loss of parallelism should occur, as two updates to the same
Kristian> MyISAM table can anyway not run in parallel.

Note that for Aria tables, multiple insert can be run at the same time.

Regards,
Monty