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: 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. Does this make it a little more of a real problem? Ole 2005/12/12, Alan Milligan <[EMAIL PROTECTED]>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jan-Ole Esleben wrote: > >>It really *is* in your interests to ensure a single request completes > >>all your functional requirements ;) > > > > > > That's not possible unfortunately. The design of the system is rather > > complex, and unalterable in this respect. However, it is not true that > > it is usually possible to fulfil this requirement. What of programs > > running on an operating system that call other programs via that > > operating system? > > > > I don't believe you. > > You have a client application calling your Zope server's bla() > function. It can do this either by HTTP or XML-RPC by choosing the > appropriate Content-Type. > > You've chosen to implement this interface by making other XML-RPC calls > to the same server to complete the task. This is both unnecessary and > bad. Unnecessary because you're doing an RPC when you've got all you > need in local memory. This is bad because you're introducing the > additional overhead of setting up said RPC. Worse, you're now > responsible for your own transaction management because you've split the > task across multiple ZODB connections. > > You need to think about the *correct* way to write your bla() function. > In doing this, you want to be able to take advantage of the automatic > rollback facilities of Zope by keeping all of this in one transaction, > which will also avoid your initial problem of conflict errors. > > Alan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFDnNZcCfroLk4EZpkRArTDAJ96TGwDy047D09jkmRNbGyD7e+3QgCg0aNZ > lLo0znXi4qvXr5j4SseH2k8= > =hu4V > -----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 )