You did not mention what LOG LEVEL you were using.  I would suggest
setting it to BLATHER (you are using Zope 2.9.2 I believe -- the log
systems is in transition but I think BLATHER is appropriate for 2.9.2).
This will allow you to look at the transactions with a bit finer 

On Tue, 4 Jul 2006, Jonathan wrote:

> ----- Original Message ----- 
> From: "Dennis Allison" <[EMAIL PROTECTED]>
> To: "Jonathan" <[EMAIL PROTECTED]>
> Cc: <>
> 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!
> Jonathan


Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to