[Zope-dev] CORBA-ZODB: Is replacing global get_transaction() the only way...

[John D.Heintz]

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