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

Get your own FREE, personal Netscape WebMail account today at 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to