"John D.Heintz" wrote:
Hi all,
I am about to embark on integrating ZODB with CORBA,
Woo hoo!
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,
That depends on your point of view. The Zope publisher (ORB) largely automates transaction management for application programmers, so they don't have to deal with identifying transaction boundaries. So, from an application point of voew, these details are hidden.
From a system point of view, Zope does manage per-thread transaction data. This is something a CORBA interface could provide as well.
IMPORTANT NOTE: The ZODB-provided transaction manager automatically manages per-thread transaction information. Were you aware of this? This sounds like what you need.
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,
This would be nice. Basically, you want to open a ZODB database connection and begin a transaction at the beginning of the request. At the end of the request, you want to commit or abort the transaction, depending on whether an error occurred, and close the connection.
and make sure that the right transaction is called for "register".
If I understand your requirements, then the standard transaction machinery should do this for you.
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.
I'm not sure what this is, but I think it probably isn't necessary.
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.
Is there a one-to-one relation between threads and connections (or, more precisely, is it the case that there is never more than one simultaneous connection per thread)? If so, then get_transaction() should do the right thing.
2) Replace the get_transaction() in globals to return the appropriate Transaction regardless of thread.
It currently returns a different transaction depending on the 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.
I dunno. You'll probably be able to tell from my response. :)
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.
I sincerely hope that no ZODB changes are necessary.
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.)
No. Multiple threads can be accessing the same logical object. Each thread has it's own copy (and DB connection and transaction). Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.