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
