Hey
marc fleury wrote:
> > Something must have dropped out midstream.
> > I am asking here about your train example for transactions.
> > NA in my reply is North America.
> > If I am moving the execution responsiblility for a task from one set of
> > tracks to another, does the original set of tracks become free? I wouldn't
> > think so as the task completion has to be reported doesn't it? If not
> > through
> > this mechanism, then how?
>
> hmmmm parallels can be tricky. Analogy thinking can be misleading.
>
> In essence, yes the "track" becomes free to carry another train. we have
> suspended the association between the train 1 and track 1 and can put train
> 2 on track 1 (another method invocation with another Tx Context running on
> that same thread). The "task" completion callback (the Synchronization
> interface or XA as well) talk to the "transaction" and associated listeners
> (wrappers, Ressource man etc ) but not to the tracks (the thread)... the
> train tracks don't care that you completed your final journey in another
> continent.
The above is incorrect. Consider this code:
public void someEJBCode()
{
int foo = someOtherEjb.doSomething(); // Call another EJB through RMI
bar = bar + foo;
}
If things were to work as you say the doSomething call would
asynchronous (since you said that the current thread continues once the
call thread is transferred to the other side). But ALL calls in Java(RMI
or not) are synchronous: call, wait, receive result.
(You can probably see at this point what is wrong with your description,
but anyway)
If that were the case then the call could not return a value. And then
the next piece of code would not work. So, track 1 has to be held until
the train returns.
> The train doesn't stop its voyage, it is not "suspended". The thread is free
> to do something else. (in case of rmi = die AFAIK, rickard? rmi pools of
> thread re-use?)
No. See above.
> JTS "suspend" is suspend the "transaction", aka, the voyage (like freeze the
> train in time)
Exactly, while the "train" is on its voyage ("RMI call transfer"), and
then it is resumed at the other end.
> JOnAS tm.setPropagationContext(null) or jboss2.0 tm.disassociateThread() are
> the "suspension" or more precisely "association/disassociation" mechanism
> between thread-tx we are looking for..
That would lead to several physical threads being associated with the
same tx at the same time. I cannot twist my mind to see how that can be
correct...
Marc, do you see my point? Do you think I'm wrong?
Basically, the question is:
Can a tx be associated with more than one thread at a time?
If no: TM.suspend/resume is right
If yes: get/setPropagationContext is right
What's the right choice?
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
