Toby Dickenson schrieb:
On Sunday 02 February 2003 3:40 pm, Dieter Maurer wrote:

This is flawed as error handling is done outside of a transaction.

Excellent analysis. A futher problem is that this could cause dangling references, and a subsequent POSKeyError, since persistent objects can be passed from one transaction to the next inside the exception and traceback.

The same applies to your prorosed fix. Is there a need to allow the error handling transaction to commit? I propose it always be aborted.

When exactly can we get these dangling references? We are experiencing POSKeyErrors quite frequently these days. It's always the same: Some objects seem to become "dangling references" because of something we don't know yet. It's always objects that have been commited recently, though I don't know exactly if there always is an error involved that might interrupt the commit in some way (No feedback from the users). Then when the database is packed the objects are removed, and POSKeyErrors are the result.

We are heavily depending on sessions, so the scenario you are describing could be our problem.

How hard would it be to get this patched for Zope 2.6.1 final? At least as an option that can be activated when needed?


iuveno AG

Joachim Werner


Wittelsbacherstr. 23b
90475 Nürnberg


Tel.: +49 (0) 911/ 9 88 39 84

Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to