[Zope-dev] Conflict Errors

[Chris Withers]

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