Hi,
I'm not sure there is a problem at all. What I am opposing
is the assumption that a transaction only runs in one
logical thread (ie. "river never splits"), as this may not
hold in the near future. I am not thinking about possible
specification changes - just better interoperability with
other systems.
"Rickard �berg" wrote:
> 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.
I agree that this is not possible in a pure Java/EJB/JTA/JRMP
environment. But my point is that we may want to interoperate
with other systems where this is possible, and in that case
both streams of the split river may enter jBoss.
> There is no problem, so don't invent one, please.
In this case I only "invent" IIOP support with transaction
propagation for jBoss invocations.
> > 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.
Ok. So no problem here?
> > - 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.
So we have logic to handle a "split river" situation?
That is what I was afraid we might not have if it is
assumed that "split river" can never happen.
> > 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.
Note that the Splitter thread never blocked. It runs
concurrently with both jBoss invocations. Yes, it could
block while waiting for response, but it could also
busy-wait in a loop that polls for responces.
As a user I would expect to receive either a normal
return or an exception for both invocations (ie. no
deadlocked thread in jBoss). When a normal return or
exception has been received for both invocations,
Splitter can commit the transaction.
> > - Splitter can now commit the transaction.
BTW: Does RMI have a facilty for doing non-blocking
invocations like in the above CORBA example?
I am asking because such a facility complicates the
implementation of checked transactional behaviour
quite a bit.
> 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.
I am not assuming future specification changes here.
Agree that we should code to the specs as "they are",
not as we think "they may be" in the future.
Best Regards,
Ole Husgaard.
