[Zope] Trying to trap ConflictError

Jonathan dev101 at magma.ca
Tue Jul 4 13:46:37 EDT 2006

----- Original Message ----- 
From: "Dennis Allison" <allison at shasta.stanford.edu>
To: "Jonathan" <dev101 at magma.ca>
Cc: <zope at zope.org>
Sent: Tuesday, July 04, 2006 1:27 PM
Subject: Re: [Zope] Trying to trap ConflictError

> Johnathan,
> I have been lurking, following your thread, but not paying full
> attention.  Excuse me if thes points have been made before.
> There are many long threads on Conflict Errors.  You should read them.
> Note that there have been significant changes in management strategy
> beginning with Zope 2.9.X.
> A "Conflict Error" is not really an error in the usual sense;  it is an
> indication of conflicting transactions in the ZODB, that is, transactions
> have violated the optimistic locking used by the ZODB.  In general,
> Conflict Errors are resolved without problem.  The resolution usually
> involves rolling back the older transaction and committing the newer
> transaction.  When the actions associated with the rolled back transaction
> are not themselves fully transactional (for example, a file write) there
> can be unanticipated side effects.
> Your conflicts appear to be in Temporary Storage which is used for
> Session Variables.  The version that ships with Zope is flexible and
> complex and, IMHO, overkill.  Moreover, it has some unexpected properties,
> the most significant is that, even though session variables are stored in
> RAM, it occasionally uses the ZODB to manage session variable expiration.
> You can often decrease the number of session variable induced conflicts by
> increasing the lifetime of session variables.

As both you and Andreas have recommended, I have started researching 'ZODB 
Conflict Resolution' and if I come up with generic/reusable external method 
application-level solution I will post it.

By way of providing more information:

I am not using sessions.  I am using  TemporaryStorage to hold small, 
custom-made, short-lived image objects (the use case requires that each user 
views a static image with a custom overlay, and that the user accesses this 
customized image via an html img tag). The custom images are viewed only 
once, and then can be deleted. Hence the use of TemporaryStorage (to 
eliminate many disk writes and ZODB bloating). The image objects stored in 
TemporaryStorage are never overwritten, edited etc (which is causing me some 
confusion as to why the conflict errors are occurring), they are simply 
created, stored in the TemporaryStorage folder (actually a BTreeFolder2 
folder contained within the TemporaryStorage folder) and then 2 minutes 
later are deleted.  I am guessing that the conflicts are occuring as the 
TemporaryStorage is trying to delete old images while new image object 'add 
requests' are piling up, but I have yet to determine the cause of the 
conflict with 100% certainty (conflicts only occur under heavy loading, and 
not always in the same place in the load testing).

Thanks again for everyone's help!


More information about the Zope mailing list