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? Ole 2005/12/12, Alan Milligan <[EMAIL PROTECTED]>: > -----BEGIN PGP SIGNED MESSAGE----- > 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 > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFDnN2ACfroLk4EZpkRAkQ7AJ4rTWpmldRq1GoPGIV8r0CT7+VPJwCZAbKB > 5PBuLd5sJgh7QZe1ey8lZ9g= > =3TrG > -----END PGP SIGNATURE----- > _______________________________________________ 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 )