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
> > >
> > >
> > >
> > >
>
>
>
