Comment 12 for bug 1514608

Great, pleased that was helpful. The JMeter plan is fairly unsophisticated, a better plan would parse the response and adjust accordingly. In the mean time your response code approach is a good suggestion.

Out of interest, is it easier to trigger the deadlock problems if you drop the transaction isolation level back down to REPEATABLE READ?

Deadlock info from "show engine innodb status" would be very helpful in identifying the root cause of the deadlocks. Even if the decision is to go transaction-free for MySQL....it might be useful further down the line.

When I looked at this before I don't think I quite appreciated how much other stuff is happening between the db_begin() and db_commit(). So moving file operations out of this would be good anyway.

> Although it's strange to me, because I have not heard of any deadlock problems with Mahara in Postgres.
> Instead, the site tends to just slow down under heavy usage. Although perhaps that's Postgres being
> willing to wait longer for the deadlock to clear?

Maybe but PostgreSQL and MySQL have different strategies for dealing with transactions and overlapping updates. The other thing I've just spotted is that slightly different SQL is being used on the two platforms. There are some 'FOR UPDATE' clauses which are only applied in the case of PostgreSQL (in lib/dml.php) which might have some impact. Will investigate...

And while I think of it, MySQL 5.7 has a number of changes that might be important later. See the details around "index lock contention" on http://mysqlserverteam.com/whats-new-in-mysql-5-7-so-far/