MySQL Version: 5.0.54-enterprise-gpl-log MySQL Enterprise Server (GPL)

I have just had an issue with Innodb and transactions where i would get a ‘[1205] Lock wait timeout exceeded; try restarting transaction’.

To resolve it I had to mysql dump the offending table, add an index to it and then re-import it.

If php crashes, it kills the parent apache child along with it, and there’s no process to close the socket to the database. In this case your server’s tcp_keepalive timeouts will have to come along and harvest the connection for you, and the default timeout for tcp_keepalive is 2 hours… lowering it to 5 minutes or something might help.

But the real issue is why is php itself crashing. Generally speaking, php shouldn’t crash, and if it is, you might want to look at bug reports and try upgrading to see if you can get it to stop crashing.

OTOH, it could be the persistant connection thing if php itself isn’t crashing and it’s just your script hanging.

A – create table ed (id int unsigned, name varchar(10)) engine=innodb;
A – begin;
A – insert into ed set id = 1, name = ‘one’;
B – begin;
B – update ed set name = ‘two’ where id = 1;

B will hang until A commits/rollsback. If enough time goes by, you get ER_LOCK_WAIT_TIMEOUT.

Moral: keep transactions as short as possible.

ER_LOCK_DEADLOCK can be exacerbated by triggers since triggers can increase the length of the implicit transaction of an insert/update as well as the index locks (especially foreign keys) acquired. Also, don’t forget that summary triggers like “update parent set column = column + 1 where primary_key = ##” lock parent’s row until the original statement is completed.

Moral: make update/insert statements (including triggers) as quick as possible

Yes, that is really strange.

Also I agree that 1205 for web site should be handled in different way, I showed part of code for batch-process.

I’m using the PHP mysqli API and doing a basic insert into an InnoDB table. My database class starts a transaction with a “$mysqli->autocommit(false)”, then executes an insert SQL statement, and completes with a “$mysqli->commit()”. It works fine……..

…… until PHP bombs mid-way due to a coding bug. So the insert happens, but the script dies doing some other stuff before the commit() occurs. I thought the database would rollback – but instead it remains locked. Another PHP script attempting to insert takes 50 seconds to time-out with a “1205 – Lock wait timeout exceeded; try restarting transaction”. The 1205 error won’t go away until I restart Apache. For whatever reason, the resources are not released until the process is killed.

I found that an ‘exit’, instead of a PHP code bug, will not cause a problem. So there is an auto-rollback mechanism in place – it just fails miserably when PHP dies unexpectantly. Having to restarting apache is a pretty drastic measure to overcome a code bug.

To avoid this, I use “register_shutdown_function()” when I start a transaction, and set a flag to indicate a transaction is in process (cause there is no unregister_shutdown_function()). See below. So the __shutdown_check() routine (I think it needs to be public) is called when the script bombs – which is able to invoke the rollback(). This seems to work fine.

public function begin_transaction()
{
$ret = self::$mysqli->autocommit(false);
$this->transaction_in_progress = true;
register_shutdown_function(array($this, “__shutdown_check”));
}

public function __shutdown_check()
{
if ($this->transaction_in_progress)
{
$this->rollback();
}
}

public function commit()
{
$ret = self::$mysqli->commit();
$this->transaction_in_progress = false;
}

public function rollback()
{
$ret = self::$mysqli->rollback();
$this->transaction_in_progress = false;
}

I notice your code above has a loop on the 1205 (and 1213) error. In my case, each attempt take 50 seconds to time-out – I’m assuming that’s standard (I haven’t tuned anything). So your script could loop for 5000 seconds. Perhaps a better solution is to use timestamps and max out based on duration, rather than a fixed loop?

even of you do not lock anything manually there could be statements which come into deadlock, consider for example 2 update statements updating the table going by index one going in forward order and other in reverse order. These will deadlock.

Is it fair to say that a deadlock can’t happen if you are exclusively using InnoDB and not manually locking things? I’d like to believe that InnoDB does locking internally in a consistent and safe manner…

Lock wait timeout can happen in two cases – in case of cross storage engine lock wait (in which case it well can be deadlock) or most commonly in case of too long lock which can be high load or simply some long running queries.

deadlocks however can handle even with light load – it is more question of probability.

I suspect that for most applications you would be better off looking for the source of the long running lock rather than wrapping all your queries in a retry script (which strikes me as being problematic in the context of transactions).

Still, thanks for the post – I wasn’t aware of this MyISAM->InnoDB gotcha.