Hi!
Ole Husgaard wrote:
> It may not be allowed in EJB, but I worry about what
> will happen when we get better interoperability with
> other systems.
>
> Please note that generally transactions are not tied
> to threads and threads are not tied to transactions.
> The association of transactions to threads is not really
> part of the way transaction managers work: It is only
> for convenience, and only works locally.
<snip>
>From the point of JTA/JTA a transaction is indeed bound to a
thread(/threads), and there is no way to "split it". I see no point in
fearing possible changes to these specs in the future.
There is no problem, so don't invent one, please.
> I'll try to give another scenario where the river splits
> in a non-EJB system. This is a CORBA system. CORBA has
> this special feature that you can send out a method
> invocation request without blocking until the reply comes
> back. It goes as:
> - Client calls non-EJB CORBA server Splitter.
> - Splitter starts a transaction T.
> - Splitter does a non-blocking method invocation to jBoss
> bean A. This invocation carries the context of T.
> - Splitter continues concurrently with the bean A invocation
> as the invocation was non-blocking.
> - Splitter does another non-blocking method invocation
> to jBoss bean A. This invocation also carries the
> context of transaction T.
And at this point the A invocation follows all the (relevant!) semantics
of reentrancy and should be blocked if the bean is marked as
non-reentrant.
The reentrancy check is there to make sure that beans that don't like
two threads acting simultaneously on it can rely on the container to do
this. If in the future the scenario you outline should happen then it is
equivalent to a "real" reentrant call and should be blocked.
> - In jBoss bean A we now have two different invocations
> at the same time for bean A in the same transaction!
Reentrant call, which may be illegal. Would be caught by the same logic
as a "real" reentrant call.
> A little cleanup to complete the picture, assuming jBoss
> can handle the above situation:
> - Splitter waits until both invocations on jBoss bean A
> have completed, and reads the invocation replies.
Would not get here if reentrancy was checked for.
> - Splitter can now commit the transaction.
>
> > My case still holds IMO: there is only one logical thread of execution per
> > transaction.
>
> I hope you can see how we can get two logical threads of
> execution in the above scenario.
>
> Similar things could happen in jBoss if we were allowed
> to fork new threads: The new thread is not by default
> associated with a transaction, but a simple call to
> TxManager.associateThread() could fix that.
And again, we are not allowed to fork new threads according to the JTA
spec.
If the spec changes in the future, then let's change our implementation
accordingly. I don't like to code for a "would be" spec, that isn't even
likely IMHO.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
