On 12/17/05, Jan-Ole Esleben <[EMAIL PROTECTED]> wrote: > It's not about the threads or processes being tied up and waiting, > it's about the transaction breaking: because the internal call (the > one from the second server back to the first) changes the object on > the first server, and thus when the first server checks wether the > object has changed after the transaction should close (during the last > return), it finds that indeed it has, and before it could write to it, > so it raises a conflict error invariably.
This is still not a problem that has anything to do with Zope or persistenace, but it is quite simply just a conflict error. It will happen anywhere you do things like this. It will also only happen when you, in the processor of modifying an object, calls a method on another server, which, before that call finishes, makes a call back and modifies the *same* object. I can't currently dream up any scenario where this happens, but I'm happy that Zope raises an error when it does. A system that does NOT raise an error in this situation is broken. If you get problems like this, you need to make changes to the software so that this does not happen. The right way to do that depends on your application. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )