Am Mittwoch 22 Oktober 2008 00:03:51 schrieb Marius Gedminas:
> On Mon, Oct 20, 2008 at 06:56:39PM +0200, Hermann Himmelbauer wrote:
> > Just by chance, I pressed the reload button of my browser for quite some
> > time, so that my Zope3-based site was reloaded over and over. I was
> > surprised to find the following in the logs:
> >
> > 2008-10-20T18:45:15 WARNING ZopePublication Competing writes/reads
> > at /BSPSite/act/s/info: database conflict error (oid 0x0733, class
> > zope.session.session.SessionData)
> >
> > Can someone explain me why this happens, if this is something dangerous
> > or if I can forget about it?
> This happens whenever two parallel transactions try to modify the same
> persistent object at the same time.  The first one of those will
> succeed, the other will raise ConflictError, and then the Zope publisher
> will emit this warning to the log and retry the request, up to a certain
> number of times (either 3 or 5, I don't remember exactly).
> It is mostly harmless.  If you get many conflict errors, performance
> will suffer, and if you get too many, eventually the 3 (or 5) retry
> limit will not be sufficient and your end-users will see system error
> pages.

Ah, I see, now I understand it.

> > I tested the site with Apache Bench (ab2), with many concurrent requests
> > and could not reproduce the problem.
> Interesting.  Could you reproduce the problem by pressing the reload
> button again?

Yes, I can reproduce this any time. But I looked into it further, and it's 
quite weird:

- If I access the site without having logged in (= a new cookie/session is 
created), it does not happen.
- If I login, pressing F5 rapidly triggers these warnings.
- BUT: If I logout and press F5, the warnings are still there.
- If I close the browser/reopen it (-> New session), the warning is gone.

So it seems, once the session stores/has stored login information, this object 
leads to a conflict. Interesting - but I still don't know what this object 

And as Apache bench does not use sessions (as it has no cookies), the problem 
never arises.

> Sometimes Zope uses a pattern of creating a nonexistent object on first
> access.  This can cause a conflict error if two requests try to create
> that object, but it will happen only once.

Hmmm, I don't really understand what this means - how does that happen, and 
why would Zope create a nonexistent object?

Anyway, many thanks for your help, I'm quite relieved that this is no serious 

Best Regards,

GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to