[Zope] Zope Persistence (was: XML-RPC within ZOPE)

[Lennart Regebro]

On 12/17/05, Jan-Ole Esleben <esleben at gmail.com> 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/