Cool, again good luck...can't wait to play around with the fixed code.
-Charles
marc fleury wrote:
> well yes, what you propose works, and we have a similar solution for that
> problem.
> the *second* problem is in the context-MI tx holding. That is broken right
> now...
> so the scenario tx over many invocations doesn't work properly. Hold on I am
> there
>
> marc
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
> > Sent: Tuesday, September 19, 2000 8:22 AM
> > To: jBoss Developer
> > Subject: Re: [jBoss-Dev] Transaction suggestions
> >
> >
> > 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
> > > >
> > > >
> > > >
> >
> >
> >
