Hey all -
Boy, it's been a long time since I've hung around here. Anyway, I think
we've found a bug somewhere in the zope transaction machinery. Every
now and then, a backend will get into 'idle in transaction' state. After
that, no work on that backend ever commits - the 'END' query just never
Careful analysis of the log files indicated that the ZpsycopgDA instance
started 'losing' proper transactional control after an admin who was
logged in via an exUserFolder that _also_ used that DA for authentication
used the management interface to undo a Zope transaction. The transaction
in question was merely an edit on a DTML file. No db interaction beyond
the authentication. Either a successful or an unsuccessful attempt to
rollback causes the problem.
Seems the Zope transactional machinery has 'forgotten' that our connection
needs to be told about transaction boundries.
We can make this happen at will, with Zope 2.4.3 or 2.5.0, exUserFolder
0.10.7, and ZpsycopgDA 1.0.5. It does require using the usAuth (User
Supplied Auth source) part of exUserFolder. Our developer who's somewhat
familiar with the guts of exUserFolder thinks that this is probably still
a bug in Zope, since all usAuth does is use customized ZSQL methods to
change where various strings are stored in the DB.
We're seeing similar problems with ZpopyDA, but haven't tested it
thoroughly to see if it's the same trigger.
I've constructed the test case for this: it's available at:
That tarball contains an SQL schema script, zexp, and minimal instructions
for replicating the problem.
Anyone have any clues as to where to look to fix this? We're losing
commits to our database, whenever a developer tries to Undo something:
Ross Reedstrom, Ph.D. [EMAIL PROTECTED]
Executive Director phone: 713-348-6166
Gulf Coast Consortium for Bioinformatics fax: 713-348-6182
Rice University MS-39
Houston, TX 77005
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -