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
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
- 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
> 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
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -