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 connec
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
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
comme
Dennis Allison wrote:
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
at 1190763820>
Traceback (most recent call last):
File "/usr/local/src/zope/Zope2.8/lib/python
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
at 1190763820>
Traceback (most recent call last):
File "/usr/local/src/zope/Zope2.8/lib/python/transaction/_transaction
Dennis Allison wrote:
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
0x450431cc> at 1190763820>
There should be a traceback here, or if the
