> Isn't the decision of letting a thread entering the int'r chain
> indipendent
> of the context state (I mean if there is a TX associated with it and the
> likes) ? The assistant just says: you (the thread) requested with
> this pass
> (the id) to enter that door to see the jboss (the bean) ? The
> jboss is busy,
> you have to wait that the other person exits. The assistant (the
> new int'r)
> does not care what you do inside (TX, activation / passivation) with the
> jboss, or if you carry some heavy bag (TX) with you.
>
> You dug more than me, it won't work at all ?
The gate keeper (assistant) does care about the Tx, since it will not let
the thread enter if the tx is not the same as the one associated with the
ctx. There is a second level assistant that only cares about the "lock" and
that is the one you are describing. This one says "ok I know you are all
participating to the same transaction, but please let's do this in order".
The 2 assistants approach might work I don't know, I am in the middle of it.
The final (small) problem I see is that unlike what I believed with the new
interceptor, we can't really decouple the ctx acquisition from the lock
since if we do (as in another interceptor) then if the previous thread
throws an exception then the IAcq removes the instance and the thread needs
to back out to the IAcq to get a new ctx.... yeah... mypointexactly not
pretty.
marc
>
> Regards
>
> Simon
>
> >
> > give me some time
> >
> > marc
> >
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of Bordet, Simone
> > > Sent: Thursday, September 21, 2000 3:45 PM
> > > To: jBoss Development Mailing List (E-mail)
> > > Subject: RE: [jBoss-Dev] The new caches for entity and
> > stateful beans
> > >
> > >
> > > Hey,
> > >
> > > > looking at the sync....
> > > >
> > > >
> > > > For example: call A has Tx and runs on entity with SUPPORTS
> > > > and associates a
> > > > previous transaction to the instance finally it returns, the
> > > > Tx is running.
> > > > In your finally block you setCalled(false) and release the
> > > > ctx. next thread
> > > > comes in and setCalled(true) but let's assume that this
> > > > thread comes with a
> > > > different Tx, since the tx is still running we go in and mix
> > > > Tx. Problem.
> > >
> > > Ah, I see. That was the chicken-egg problem wasn't it ?
> > > What about adding an interceptor above the TX one that handle
> > > concurrency ?
> > > Just an idea (maybe wrong), but I propose it to you:
> > > In the int'r chain we have the id. This has a logical 1-1
> > mapping with a
> > > context in our impl. We cannot sync the id directly, since for each
> > > invocation they are different objects; but we can map pairs (id,
> > > mutex) in a
> > > hash table (given that the hashCode of all the ids
> > representing the same
> > > bean is the same), and sync the mutex that will be the
> > *same* object for
> > > concurrent calls. Then we can serialize, one after the other, the
> > > concurrent
> > > calls to the tx int'r and down. And we can test (move?) in
> > this new int'r
> > > (we also do in the instance int'r) the reentrancy of the
> > bean; if allowed,
> > > we allow the thread down concurrently, otherwise not (the same
> > > apply for EJB
> > > calls).
> > >
> > > WDYT ?
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > >
> >
> >
>
>
