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
