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

[Jan-Ole Esleben]

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.

Ole


2005/12/17, Chris McDonough <chrism at plope.com>:
> > The problem setup is this; I explained it above, but it this has
> > become a long thread:
> >
> > I write a ZOPE product. I want to make use of other software on the
> > internet and the services that software provides. So I use the methods
> > exposed by that software via SOAP, XML-RPC, whatever.
> >
> > One of those methods actually calls my product back, maybe because the
> > developer has learned that my product itself exposes some (or all) of
> > its functionality via XML-RPC. If this is all inside one call, which I
> > can't avoid explicitly as the developer of just my product, I have a
> > broken transaction on my hands that isn't easy to fix (and maybe
> > impossible). This holds true for the whole product, even if the method
> > called by the second server changed some completely unrelated data.
>
> I see what you're saying, but how is this specific to Zope?  If you
> write a Perl program and expose it via mod_perl on Apache, and the
> program calls out to a service that calls back in to the mod_perl
> program (no matter how broken of a pattern this was), wouldn't the
> Apache process that was waiting on data be tied up in the same way?
>
> - C
>
>