Okay, I made some progress with the UserTransaction stuff. I couldn't
do much testing yet, but with my inexperience with the code, I thought
I'd just let you guys in on my line of thinking and see if I was way off
base.
To implement UserTransaction support, here is what I did:
1. Changed TxManager to implement UserTransaction and
javax.naming.Referenceable. The UserTransaction thing was easy...all
the same functions are defined for the TransactionManager interface.
Since we only have a single transaction manager, and all the underlying
transactions are thread-local, it makes sense to only have a single
UserTransaction object. And, since a separate UserTransaction class
would only be a glue layer over TransactionManager, why not make them
the same class? Implementing Rererenceable only needed one additional
method: getReference(). The significance of this comes in later...
2. In TransactionManagerService, in addition to binding a Reference to
TxManager to the name "TransactionManager," I also bound it to
"comp/UserTransaction," creating the comp subcontext if necessary. This
will provide support later for in-VM non-bean clients, like Tomcat
servlets, to look up a UserTransaction.
3. In Container, in the setupEnvironment() function, after creating the
"comp" subcontext, I lookup "comp/UserTransaction" from the
InitialContext(). Then, I cast it to a Referenceable, and bind the
result of getReference() to "comp/UserTransaction" in the bean's
thread-local java: namespace.
As far as I can tell, that will do it. I still can't get non-bean
clients to look up a UserTransaction, mainly because Tomcat in
particular uses its own brand of ClassLoader, which screws up trying to
dereference a TxManager. At first, I had the problem of not having all
the necessary classes in Tomcat's classpath, but even if I make sure all
the needed classes are in Tomcat's classpath, it seems to hang when I
try to load the servlet...no exception thrown, the web browser just sits
there trying to load it. What might not be a bad idea is to bind the
actual UserTransaction object, rather than a reference to it, or to use
another class besides TransactionManagerService as the ObjectFactory...a
class with fewer dependencies. TransactionManagerService depends on all
that JMX stuff that clients really don't care about. I'm not a JNDI
expert (quite the novice, actually) so I don't know exactly what that
will do...will it just store the object itself, or will it try to
serialize it then deserialize it later, etc.?
So that's my $0.02 worth. I recall that Marc and Sebastien were working
on some fixes to make UserTransactions and BMT work. How are those
coming along?
-Charles
