> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> Sent: Thursday, August 03, 2000 11:00 PM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] rmi,transactions,orbs [was: TransactionImpl]
>
>
> 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?
no you are not wrong on a RMI call in but I was talking on a RMI call out of
the container.
If you call suspend the "transaction" normally all the listeners on the
transaction are notified that the transaction has been suspended... the
"suspend" call is a distributed one, propagated to everybody.
You don't want to let everybody know you remove an association of the
thread, it is a purely local event, not a global one, in fact the
"Transaction" itself is not really interested in the fact that it is
associated to a thread or not, it is a "standalone" concept . Suspend is a
global event on the transaction (like begin, commit, rollback, suspend,
resume see?).
With regards to the example, we use "disassociate" on the way back from the
invocation, not on the way *in* to the invocation (hey it's your own code
kid :) and once the container is done with the invocation layer way in and
way out, we could possibly reuse the thread for another invocation (and I
understand RMI doesn't do this, does it?). That thread would then be reused
with another Tx on the way in and a new "associate". Is this better?
Examples can be misleading.
Finally with the "multiple threads per transaction" mind twisting, it got me
all nostalgic. I don't know if you remember kid, but the first time you
joined the group we started fighting over this "many threads" per TX .
Since a transaction is a standalone object that encompasses many VMs over
time (here and now in software), I always envision it with many threads
running in it, almost by definition, since we use the transaction to
synchronize the work of many threads running in parallel on a task to be
done.
> Basically, the question is:
> Can a tx be associated with more than one thread at a time?
of course, if not what is the use of it in a distributed fashion?
btw I of course read your mail where you finally read it :0)
regards
marc
> 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
>
>
