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 <alan@balclutha.org>:
-----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-----
Jan-Ole Esleben wrote:
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).
That depends on your thinking...
I tried doing my own commits, but it doesn't work, it just bombs earlier (no matter where I do them).
You;re not giving us a lot of info here, but I think you need to read the code in lib/python/ZPublisher in depth if you really need to play at this level...
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.
Well, you could start by showing us the errors you're getting...
It is not possible to do _really_ explicit transaction management with ZODB, is it?
Of course it is. But you're talking about Zope here, not ZODB. Zope manages transactions so users don't often have to worry about them. If you want to manage transactions within Zope, the nyou have to understadn and co-operate with the transaction management that Zope does... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (2)
-
Chris Withers -
Jan-Ole Esleben