Hi!
"Kristian" == Kristian Nielsen
writes:
Kristian> Kristian Nielsen
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