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.
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 :-)
thanks
david jencks
-dain
