hi there,
Yes we did pretty much the same thing to bind the UserTransaction (but we
use a inner class and a factory). We noticed also that the UserTransaction
could be a singleton essentially. The tricky part is the spec
implementation of the behaviour. (T1 and T2 stuff) so that if a StatefulSB
keeps association over several calls then the Tx is seen.
I do believe that you miss the fact that the Context is now responsible for
holding that reference (i.e. the Tx the in context must point to the
underlying tx). That is when you run in problems since the
setMethodInvocation on an instance passes the transaction to the instance
context and that is no good right now (we override the instance Tx with the
MI Tx).
To change that is where the rubber meets the road. For that I need to
significantly rethink the Instance Synch (as in thread concurency, not the
state stuff). It is the way to solve the chicken and egg problem.
In short it is kind of deeper in the container and our test (Sebastien wrote
TestBeans to test many UserTransaction scenario) shows that the bean ->1st
method bean -> 2nd method in case of BMT stateful with the first method
tx.begin() and the second method doing a tx.commit() essentialy breaks down
the tx associations.
The main reason is that the stack of interceptors needs to be more aware of
BMT and CMT.
I will try to solve this today with Sebastien, hold on, we will try to get
you something by the end of the day. At any rate I am interested in seeing
your diffs on the UserTransaction stuff and compare notes. Final thing, I
know you claim you are a newbie on JNDI (but so is everybody ;-) if you
could give that a try at implementing the right context (the ideas pitched
the other day about thread localness of java:) that would be kick ass. Let
me know if you want to go tackle that horse...
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
> Sent: Tuesday, September 19, 2000 6:58 AM
> To: jBoss Developer
> Subject: [jBoss-Dev] Transaction suggestions
>
>
> 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
>
>
>
