The problem is that it isn't my design, and the design is part of a
contract. I can't really do anything about that (the major problem is
that there will be SOAP components that might even need to be
transparently integrated - which completely excludes ZEO). I tried
doing my own commits, but it doesn't work, it just bombs earlier (no
matter where I do them). I really don't know why, my only guess is
that something about the transaction management breaks terribly when
you go back and forth between objects without them being able to track
it. Only I cannot figure out what.

It is not possible to do _really_ explicit transaction management with
ZODB, is it?


2005/12/12, Alan Milligan <[EMAIL PROTECTED]>:
> Hash: SHA1
> Jan-Ole Esleben wrote:
> > OK, the following is the case:
> >
> > The setup is for functions dispatching either locally or via XML-RPC.
> > At the moment, the mechanism I use is to detect locality is flawed and
> > thus doesn't work well. So I have local XML-RPC calls where I could
> > have global ones. But.
> >
> > 1. I need that possibility for testing the XML-RPC setup. I cannot set
> > up multiple instances for every cheap test. At least I shouldn't have
> > to. The very important reason, however, is:
> > 2. This is a generic call dispatcher. It is used, for example, for
> > object name resolution in a widely deployed system. So, what could
> > happen and couldn't happen locally is this:
> Zope isn't CORBA.  ZEO is the correct way to scale/cluster Zope's.
> >
> > 1. Server1 dispatcher calls, via XML-RPC, Server2.
> > 2. Server2 dispatcher calls Server1, which does something locally
> > (same communication management object as the dispatcher, maybe another
> > local call) and then returns
> >
> > This is the same problem spread out over two servers, where locality
> > isn't possible anymore. The call from Server1 to Server2 must be made
> > via XML-RPC and I cannot exclude Server2 calling Server1 back.
> If you really must architect your solution this way, then you are going
> to have to do your own transaction management.  Your 'local' calls need
> to do explicit commit() calls and you're going to have to reread
> 'tainted' objects.
> Again, it will take you half an hour to modify your design instead of
> half a year to get all the bugs out of your implementation.
> Alan
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> 5PBuLd5sJgh7QZe1ey8lZ9g=
> =3TrG
Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to