geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: [Discussion] Removal of TransactionContextManager
Date Thu, 03 Aug 2006 16:48:06 GMT
On Aug 2, 2006, at 11:57 PM, David Jencks wrote:

> 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:// 
>> svn.apache.org/repos/asf/geronimo/branches/dain/notcm 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:
>>
>> http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ 
>> resources/org/jencks/samples/outbound/jencks-tranql.xml?r=112
>> http://fisheye.codehaus.org/browse/jencks/branches/notcm/src/test/ 
>> 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.

As Guillaume pointed out, you don't have to expose this  
UserTransaction to the end user.  I personally don't care if the user  
gets their hands on a TransctionManager as the difference between the  
two interfaces is quite small.

>> 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?

org.apache.geronimo.connector.ConnectorTransactionContext contains a  
ConcurrentHashMap keyed by the transaction object.

>> 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 :-)

I am +1 to move to Java 5 at anytime, but this code is using the  
Executor interface Doug Lea's Concurrent library.  The Geronimo  
ThreadPool already implements this interface.

-dain

Mime
View raw message