[ZODB-Dev] RelStorage MySQL - StorageError: Unable to acquire commit lock

[Shane Hathaway]

Rudá Porto Filgueiras wrote:
> (...)
>   Module relstorage.adapters.mysql, line 506, in start_commit
>   Module relstorage.adapters.mysql, line 672, in _hold_commit_lock
> StorageError: Unable to acquire commit lock
> 
> I solve the problem restarting all instances, and the site became
> operational again, but I have some questions:
> 
> This can be a bug or there is any problem in my enviroment/application?
> There is another solution to release commit lock without restart all instances?

Perhaps some instance was taking a very long time to finish a 
transaction commit and you didn't notice it.  RelStorage does everything 
it can to minimize the amount of time the commit lock is held (it uses a 
strategy similar to ZEO), but applications are ultimately in control of 
how long it takes to commit a transaction.

A concurrent pack might provide another explanation.  Have you ever 
packed the database?

This could also indicate a bug in MySQL.  According to the documentation 
of get_lock(), all locks will be released when connections terminate, 
but maybe you ran into a MySQL bug that causes locks to stick around.

To me, the most plausible explanation is a MySQL bug, since the other 
hypotheses don't explain why one of the connections terminated prematurely.

If I were you, I would try the same application with PostgreSQL instead 
of MySQL.  If the bug persists, then at least we know it's not a MySQL 
bug. :-)

> But the question remain, why the database connection was not safely
> closed when tcp_abort fail?

The error message occurring in tpc_abort was "OperationalError: (2006, 
'MySQL server has gone away')", suggesting that the database connection 
was *already closed*.

Shane