Speaking of the <cough>messy</cough> jnp code, where is it? I dont think there
is an org/jnp dir with the jBoss CVS snapshot I downloaded. Is it perchance
documented at all? The problem is that whenever the code starts using stuff
imported from org.jnp, it is all guesswork on my part.
At any rate, I have some ideas. I will try to do some screwing around this
weekend (in-laws are over so you never know).
-Charles
marc fleury wrote:
> wow, not bad for a "first timer".
>
> You miss the first part but for the rest you are right. Listen Sebastien
> and I are almost done, we have the solution and it is indeed with a
> TxInterceptorCMT/BMT that get assembled differently so (of course) it fits
> in the current model since all the "interceptor" layout really specifies is
> that "thou shall invoke stuff in line"... yes...well yes... :))
>
> Ok seriously now. I am getting more and more warm to the usage of the
> try{} finally{} pattern in the interceptors since one is the "going in" and
> the other one is "before returning", and as a proof you will see that our
> "finally" DOES MOST THE CODE in the CMT stuff. I find that very
> interesting.
>
> Ok we are almost there and we will try to post by tonight, if we can, if not
> monday. (Actually we will finish on Monday)
>
> Since you seem to be a "stellar" contributor in the making (yes I know,
> pressure ;-) I would encourage you to tackle the java: stuff it is brainy
> and *I* was never able to understand fully the JNP code
> (<cough>messy</cough> ;-). For the order of interceptors it is done in the
> "container factory" but you don't have to worry about we got it solved.
>
> regards
>
> amrc
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
> > Sent: Friday, September 15, 2000 3:45 PM
> > To: jBoss Developer
> > Subject: Re: [jBoss-Dev] UserTransaction
> >
> >
> > Wow, nasty. As I understand it, the problem is that you need to go thru
> > txAcquisition BEFORE txInterceptor because if a BMT transaction
> > is in place, you
> > want to acquire it before you use txInterceptor to check the transaction
> > attributes for CMT. HOWEVER, you need txInterceptor BEFORE
> > txAcquisition so
> > txInterceptor can set up a transaction that will be acquired by
> > txAcquisition,
> > hence the chicken and egg problem.
> >
> > If I were more familiar with the code, I'd offer some advice.
> > I'll take a look
> > at it tonight as well and see what I can come up with. I like
> > the way you guys
> > set up the interceptor system a whole lot...good OO design and
> > allows different
> > objects to be responsible for different actions in the method invocation
> > "pipeline." It's a very flexible system and I think you guys
> > will be able to
> > come up with a solution that fits within the current model. I'll provide
> > whatever help I can...first I have to familiarize myself with how the
> > Interceptors get assembled.
> >
> > I definitely think you are on the right track, thinking that the
> > Interceptor
> > chain should be assembled differently in the case of BMT. Again
> > not knowing the
> > assembly process, I don't know how easy this is.
> >
> > If you guys can work on this, that will lay the groundwork for the
> > java:/comp/UserTransaction thing. If I can get enough time this
> > weekend, I will
> > try to implement it in parallel. Keep me posted on what is happening.
> >
> > -Charles
> >
> > marc fleury wrote:
> >
> > > OK
> > >
> > > 1- yes the tx view to Tomcat is important and a proper implementation of
> > > java: is the way to go
> > > 2- for the container we have a big problem
> > >
> > > It turns out that none of the Bean Managed Transaction was
> > really taken into
> > > account at design time. It reads like this. BMT needs to have
> > the instance
> > > and more precisely the context in order to make the right
> > decision on the Tx
> > > management.
> > > Now the InstanceAcquisition also needs the Tx to retrieve an instance
> > >
> > > however: right now the stack of interceptor goes
> > > txInterceptor -> txAcquisition
> > > when we need
> > > txAcquisition -> txInterceptor
> > >
> > > so, with a chicken and egg problem... we are
> > >
> > > fucked
> > >
> > > Sometimes modular stuff has its limits... there might be a
> > solution in that
> > > we need to actually reimplement a BMTTxInterceptor and not set the
> > > TxInterceptor for SessionBeans that work with BMT, change the order of
> > > interceptors for these puppies and make sure the spec is met...
> > more work
> > > than we thought (as usual). This is a design flaw but it is
> > good that we
> > > are testing the current design now as opposed to down the road.
> > Sebastien
> > > and I are going to take a stab at it in pure XP style and see
> > if we can come
> > > up with something by tonight.
> > >
> > > wish us good luck, this is not looking easy :(
> > >
> > > marc
> > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Charles Crain
> > > > Sent: Friday, September 15, 2000 1:07 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: [jBoss-Dev] UserTransaction
> > > >
> > > >
> > > > I'm moving this message thread here, because we are getting off topic
> > > > for the use group.
> > > >
> > > > Sebastien, your measure sounds great, and may be sufficient to go the
> > > > distance. The only concern I had is that I'd like to see one
> > be able to
> > > > look up a UserTransaction object OUTSIDE a bean, perhaps from within a
> > > > Tomcat servlet running in the jBoss environment. I think
> > that would be
> > > > very cool, but as we said it requires solving the problem of the java:
> > > > namespace.
> > > >
> > > > I do think it's probably too much of a pain (at least for now) to
> > > > provide a UserTransaction to remote clients (i.e., clients not running
> > > > in the same VM as jBoss).
> > > >
> > > > I'll fool around tonite and see what I can do.
> > > >
> > > > -Charles
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
