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 gets sent. 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: http://wallace.ece.rice.edu/xact-bug.tar.gz 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: not good! Ross -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Executive Director phone: 713-348-6166 Gulf Coast Consortium for Bioinformatics fax: 713-348-6182 Rice University MS-39 Houston, TX 77005