geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [Discussion] Removal of TransactionContextManager
Date Thu, 03 Aug 2006 06:57:50 GMT

On Jul 31, 2006, at 4:09 PM, Dain Sundstrom wrote:

> <history length="too long">
> About a week ago there was a discussion on the OpenEJB mailing list  
> regarding the TransactionContextManager.  In OpenEJB 3 we removed  
> the use of the TCM from Geronimo and replaced it with just a  
> javax.transaction.TransactionManager.  This brought all of the  
> openejb containers into alignment.  The other big motivation was to  
> ease the integration of OpenEJB and third part libraries,  
> specifically Spring.  The problem with the TCM is that if you use  
> it you can't use the TM directly since the TCM needs to know about  
> all TM calls.  Additionally, to use the TCM you must demarcate all  
> changes in "component context" by starting an unspecified  
> transaction context.  This is all quite invasive and made OpenEJB  
> hard to use in Spring or plain old Tomcat.
> That was all fine and good for OpenEJB 3, but as it turns out there  
> is a desire to keep the OpenEJB 2 and 3 code aligned as much as  
> possible, so a discussion started around how to backport the  
> changes to 2.  We determined there were two options:
> 1) wrap the TCM with a class that implements TM but delegates to  
> the TCM - this would be tricky to get working and there is always  
> the problem of demarcating the unspecified transaction context
> 2) remove the TCM from Geronimo entirely - this could be a lot of work
> After a quick look at the first option, I decided to try option  
> two.  It turned out to be a lot easier than I thought since, the  
> biggest user of TCM was OpenEJB and I had already pulled it out of  
> OpenEJB.  I also think I have become the master of using the  
> IntelliJ refactor tools and was able to remove the code without too  
> much hand tweaking.
> </history>
> I have checked the fruits of this effort into https:// 
> and there is  
> a matching OpenEJB branch that is checked out with maven m:co.  I  
> have not updated the m2 build yet, as it was finalized during this  
> work.
> For those of you that are following the Jencks project, which wraps  
> the Geronimo transaction and connector modules with Spring bean  
> factories, I have created a branch there also, which contains a  
> massive simplification due to the refactors in the removal of the  
> Geronimo TCM.  Here are some fun examples from that project:
> resources/org/jencks/samples/outbound/jencks-tranql.xml?r=112
> resources/org/jencks/spring-request-reply-jta.xml?r=112
> So what does everyone think about removing the TCM in general?   
> After that I think we may want to discuss the specifics of my  
> branch.  I may have gotten too refactory happy :)  Details on the  
> specific changes I made follow:
> TransactionContextManager
> -------------------------
> Removed TransactionContextManager and replaced all uses with a  
> plain old TransactionManager
> Removed all code from web containers, app client and timer that was  
> simply demarcating an unspecified transaction context, which is no  
> longer needed
> TransactionManager
> ------------------
> Merged XATerminator portion of TCM into GeronimoTransactionManager  
> which is a subclass of TransactionManagerImpl
> Improved tx thread association code so we can throw an error if  
> someone attempts to resume a tx associated with another thread
> Added TransactionManagerMonitor which is used by the connection  
> tracker to know when a transaction context has changed
> UserTransaction
> ---------------
> TransactionManagerImpl now implements UserTransaction to ease  
> integration with third party libraries such as Spring

Why is this a good idea?  This strikes me as a bad idea since a user  
can successfully cast UserTransaction to TransactionManager.

> Removed OnlineUserTransaction since it was only really used by  
> OpenEJB and it has it's own UserTransaction implementation
> Web containers now use GeronimoUserTransaction which is an always  
> on wrapper around a transaction manager
> Third party support
> -------------------
> Moved use of ServerInfo from HOWLLog to HOWLLogGBean so it can be  
> more easily use by third party libraries
> Moved connector related transaction data to connector module

I guess considering the number of threadlocal accesses and hashmap  
lookups in this code possibly adding one more isn't going to cause  
problems.  How do you associate the data with the transaction?

> Replace use of Geronimo's thread pool with a concurrent executor

Is this java 5 only?  If so how is our retrotranslator testing  
going?  Having just read the "concurrency in practice" book I'm eager  
to move to java 5 now :-)

david jencks

> -dain

View raw message