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.
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? 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.
I use session.PersistentSessionDataContainer for my session, so every request will probably read/write to some Zope3 container/btree. And then, for some reasons these reads/writes compete, which leads to the above warning. If I use AB2, there's no cookie, thus no session, hence the problem does not arise.
On the other hand, the zope root site (the Rotterdam ZMI) seems not to have this problem, as it seems, I can't trigger this warning message with fast reloads.
I'm unsure if I should just ignore that or do something about it.
It's a warning. It would be better if it did not occur, but sometimes that's hard to achieve and the efforts do not pay off. HTH, Marius Gedminas -- Hoping the problem magically goes away by ignoring it is the "microsoft approach to programming" and should never be allowed. -- Linus Torvalds