Hi,
Rickard Oberg wrote:
> > Be careful about assumptions here. In a pure EJB world
> > the river cannot split, but not all environments are pure
> > EJB.
> >
> > Example:
> > A bean starts a transaction and calls some non-EJB system
> > by using a resource. This non-EJB system starts two threads
> > for doing some work in parallel, and the river has split.
> > Now these two threads may both call EJB systems with the
> > original transactional context...
>
> I'm pretty sure that the above is something that is not allowed, i.e.
> forking threads does not mean that the tx is in the forked thread as well.
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.
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.
- In jBoss bean A we now have two different invocations
at the same time for bean A in the same transaction!
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.
- 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.
Best Regards,
Ole Husgaard.
