Thanks for the reply :-) Chris McDonough wrote:
It happens when more than one thread tries to modify the same object in storage at the same time. It's Zope's equivalent of record-locking... It's normal. There's no corruption or anything, it's telling you that it avoided a write that might have caused problems. Zope tries three times to retry the write. If the object is still locked by another database connection after three writes, it propogates the exception up to the app level. That's the error you see.
Hurm, well, it appears to happen when we're doing a lot of sequential write to a product (automated bulk data upload), but the thing that triggers it off is actually trying to read a page from the same area of the site... confusing. Although that could also be a one-off coincidence... You say no corruption or anything, but if a submit results in that error, does the submitted form data get processed or not?
Careful application coding can reduce the chance of conflict errors.
Can you describe what you mean by careful application coding?
I bet it happens on a catalog write for you.
No, for once it has nothing to do with the catalog. ;-) This is a python product of ours that stores lots of data in somewhat nested, persistent dictionaries. How can this be improved so this doesn't happen?
I know your next questions are going to be "why?" and "how do I fix it?" and "why don't you fix it?".
While I'd love it if you'd fix our code for free, it's probably beyond the OSS remit ;-) Any clues about how to make our code 'less bad' would be cool... cheers, Chris