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
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
> 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
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -