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 _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
