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