Hi all, I am about to embark on integrating ZODB with CORBA, and am in the deep thinking phase of the endeavor. ;-) What I want to do is _explicitly_ manage connections and transactions without being able to depend on what thread is running. I know that this is _not_ the way that Zope works, but if I want to use standard CORBA I think I have only two choices: 1) Explicitly associate Connections with Transactions in my CORBA layer. What I need to do is allow any thread to change a Persistent object from some Connection, and make sure that the right transaction is called for "register". 2) Build a complete wrapping adapter layer that does thread synchronization to the actual Persistent objects and proper thread for the transaction. - Lots of overhead and redundant coding - tricks with ExtensionClass might make this adaptation simpler to code, but still it won't be easy. Obviously number one is my preferred choice. In order to accomplish that, I see only two ways: 1) Modify ZODB to maintain a Connection to Transaction link, and modify cPersistence.c to use that link in the changed() function instead of relying on the standard get_transaction() thread index. 2) Replace the get_transaction() in globals to return the appropriate Transaction regardless of thread. Again, my preference is number one. After going over the ZODB code, I _think_ that a Connection is always associated with one Transaction. If this assumption is true, then it should be safe to make the change I'm proposing. If not, then I need to understand why so that I can rethink how to solve my problem. ;-) I hope that I've made my problems and ideas for solutions clear, if not please let me know. Also, I think that I should be able to make the changes to ZODB myself within the next few week, but only if there is the _possibility_ of folding them back into the main Zope codebase. Thanks for any help, John D. Heintz CORBA Threading description: CORBA defines the POA, which has two standard threading policies: ORB Controlled Model Single Threaded Model The POA is basically a controller for requests to one or more distributed objects, with thread policy as one of its parameters. The first threading policy means whatever the ORB gives you - single or multi, and you have to deal with all synchronizations. The second I consider a mis-nomer because there can be many threads, but only one at a time will access objects for a given POA. (This is the model that I perceive being used by default for ZODB object from a specific Connection.) -- John D. Heintz DataChannel, Inc. Senior Engineer 512-633-1198 jheintz@isogen.com ____________________________________________________________________ Get your own FREE, personal Netscape WebMail account today at http://home.netscape.com/webmail