Re: [Zope] Re: session variables in the presence of conflicts

2005-11-20 Thread Dennis Allison
Florent, There were, of course, tracebacks. Any assist you can provide would be appreciated. -D -- 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 Traceback (most recent call

Re: [Zope] Re: session variables in the presence of conflicts

2005-11-20 Thread Dennis Allison
That was my conclusion long ago, but I have not been able to track it down. It only occurs under heavy load when backing out of a conflict error. I have not been successful at creating a test set that triggers it. I suppose it is time to again read the ZMySQLDA code... There are a few

Re: [Zope] Re: session variables in the presence of conflicts

2005-11-20 Thread Chris McDonough
Hi Dennis, I notice that line 389 of db.py of the most recent ZMySQLDA (2.0.8) doesn't match the traceback you show. No mutex locking at all is done in the 2.0.8 version of that module (or any other module in that product). Are you using an older version? - C On Nov 20, 2005, at 9:57

Re: [Zope] Re: session variables in the presence of conflicts

2005-11-20 Thread Chris McDonough
Sorry, I noticed in another email you said that you're using 2.0.9 (which appears to be in beta) and I confirmed that the traceback matches that source. The note in the product's CHANGES.txt about this is: Wrap queries with a lock to prevent multiple threads from using the