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