Hey,
> Yes I was looking at the same new interceptor yesterday and I
> actually don't
> think it will work anymore... ("anything that takes a
> decision based on the
> state of the context needs to have that context locked
> previously", is about
> the only certainty I have at this point).
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 ?
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
> >
> >
>
>
