We are using MySQL but are fully transactional using innodb. The sort of problems we are seeing are (cruft removed) are things like:
2005-11-18T12:50:16 ERROR txn.3075 Error in tpc_abort() on manager <MultiObjectResourceAdapter for <Products.ZMySQLDA.db.DB instance at 0x450431cc> at 1190763820> 2005-11-18T12:50:16 ERROR txn.3075 Error in tpc_abort() on manager <MultiObjectResourceAdapter for <Products.ZMySQLDA.db.DB instance at 0x41487acc> at 1190774252> 2005-11-18T12:50:16 INFO ZODB conflict error at /courses/topics/navigation_box (55 conflicts since startup at 2005-11-18T12:13:38) 2005-11-18T12:50:16 ERROR txn.3075 Failed to abort object: Surrogate oid=<object object at 0x4009d470> 2005-11-18T12:50:16 ERROR txn.3075 Failed to abort resource manager: <MultiObjectResourceAdapter for <Products.ZMySQLDA.db.DB instance at 0x450431cc> at 1190763820> 2005-11-18T12:50:16 ERROR txn.3075 Failed to abort object: Surrogate oid=<object object at 0x4009d470> 2005-11-18T12:50:16 ERROR txn.3075 Failed to abort resource manager: <MultiObjectResourceAdapter for <Products.ZMySQLDA.db.DB instance at 0x41487acc> at 1190774252> all of which appear to be the result of the the single conflict error. The problems occur when the site is under load. To date I have not been able to find a simple instance that can reproduce the problem. Debugging in situ with a live system is not simple. In one instance, we have observed a loop where the conflict error generated resolution created another conflict error -- or so it appeared. On Sun, 13 Nov 2005, Peter Bengtsson wrote: > Have you considered upgrading to PostgreSQL? Things might have changed > since the last time I tried mysql but I'm pretty sure Postgresql and > psycopg deals much better with transactions in Zope. Admittedly, this > doesn't explain why you're getting into trouble just because you've > upgraded to zodb 3.4.2 > > On 11/13/05, Dennis Allison <[EMAIL PROTECTED]> wrote: > > Zope 2.8.4 > > ZEO 3.4.2 > > ZODB 3.4.2 > > Python 2.4.2 or 2.3.5 > > MySQL 4.0.20 > > MySQL-Python 1.2.1c3 (although we see the same problems with 1.2.0) > > MYSQLDA 2.0.9 > > > > We have just moved from Zope 2.7.6 to Zope 2.8.4 motivated, in part, but > > the ability to avoid read conflicts under ZODB3.4.2. We have been having > > a lot of problems: more conflict errors, release of unreleased locks in > > MySQL transactions, loss of session variables, and others. > > > > We use session variables and MySQL very heavily. Our MySQL tables are > > MyISAM and are not transactional. > > > > ZODB3 3.4.1 introduce some changes to the conflict resolution which > > appears to be a logical improvement but also appears to have acerbated > > our problems. In the ZODB# 3.4.2 system, if a commit fails, an exception > > is raised and the transaction is aborted. Zope then attempts to reschedule > > the transaction. The abort needs to roll back MySQL transactions that are > > part of the conflicting ZODB and the Session Variable Store so the > > restart is clean. > > > > In our case, we have been using MyISAM tables, which are not > > transactional. The rollbacks fail and the locking in the database adapter > > gets confused. Changing the table type from MyISAM to Innodb, which is > > transactional, should resolve the MySQL problems, although it has yet to > > be tested. > > > > Conflict errors also arise through the session variables. Since we have a > > multi-Zope system configuration sharing a single ZEO, the session > > variables are stored in a Temporary Storage object on the ZEO host. When > > a conflict occurs, a number of things, none good, apparently can happen. > > Session variable transactions cannot be rolled back (as the temporary > > storage mechanism is not transactional). And, at a different level, > > session variable persistence requires that transactions require a > > copy-out/copy-in mechanism to identify those changes which have been > > changed and need to persisted; an aborted transaction may not be marked as > > persistent and so will disappear at some apparently random time in the > > future when the temporary store is packed and cruft removed. > > > > Some refactoring of the programming can help minimize the potential for > > session variable conflicts, but they cannot be eliminated. > > > > If systems stability in the face of session variable conflicts is > > important, > > > > 1. Does the store for session variable need to be transactional > > and support rollbacks? > > > > and > > > > 2. What Temporary Storage object provides the right mechanism to > > manage session variables with rollback efficiently? > > > > > > > > _______________________________________________ > > Zope maillist - Zope@zope.org > > http://mail.zope.org/mailman/listinfo/zope > > ** No cross posts or HTML encoding! ** > > (Related lists - > > http://mail.zope.org/mailman/listinfo/zope-announce > > http://mail.zope.org/mailman/listinfo/zope-dev ) > > > > > -- > Peter Bengtsson, > work www.fry-it.com > home www.peterbe.com > hobby www.issuetrackerproduct.com > -- _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
