I will wait to see how you guys end up implementing all the UserTransaction
stuff, because that will affect how I'd want to tackle the java: namespace
issue. I think the way I was doing it will work -- as long as I am guaranteed
that the underlying UserTransaction class also implements
javax.naming.Referenceable (which it technically should if we are binding a
Reference to it with JNDI, right?). That way I can obtain a reference, and bind
it to the thread-local namespace of a bean type when its Container is created.
At least I THINK that will work. It all depends on how you guys end up
implementing the UserTransaction and its factory. Good luck with this tough
issue.
-Charles
marc fleury wrote:
> 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
> >
> >
> >
