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

[Jan-Ole Esleben]

That ZOPE raises an error is fine. That I _might_ run into such
situations with other tools is true. But in ZOPE, it is definitely the
case that data and program are coupled in an implicit way that makes
these cases much harder to debug and avoid, because if the two methods
in my example operate on different sets of data, which they probably
would, or if one of them did a read before calling the external method
and then afterwards a write (on an SQL database maybe), nothing would
happen if I used explicit data storage! In Zope, it's just the whole
object that's tainted. That's my whole point. I think it is a very
significant point nonetheless, because this is just an extreme case of
what happens when you couple data and programs, and persistent classes
are just that: application data inside program code. This had never
occured to me as a _real_ problem before. Of course, if you just
create self contained code on a small scale that doesn't talk to other
programs on the web, you'll likely not run into any great problems
because of this.

Ole


2005/12/17, Lennart Regebro <regebro at gmail.com>:
> 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/
>