Hi!
marc fleury wrote:
> In your example "suspend" would mean "suspend the trip" altogether, not
> suspend the trip on the railroads.
>
> Suspend in JTS, and that is how it was done in jonas, means "suspend the
> transaction going on" (the one associated with the thread since you don't
> pass anything explicitely). We just need a "suspend" on the track really
> that says "the train is no longer traveling on the tracks"...
But that's what the javadocs of suspend says:
"Suspend the transaction currently associated with the calling thread
and return a Transaction object that represents the transaction context
being suspended. If the calling thread is not associated with a
transaction, the method returns a null object reference. When this
method
returns, the calling thread is associated with no transaction."
What this means to me is that before the call the thread is associated
with a tx, and after the call it is not. Which is (IMHO) right for
propagation of context through distributed call.
Use-case:
1. EJB-call starts tx
2. EJB-call invokes some instance
3. Instance invokes a stub of another EJB
4. Stub does "suspend", and gets the current tx. Current thread is no
longer associated with the tx. The tx doesn't have "a home" in terms of
execution thread
5. Stub extracts the Xid from the tx
6. Stub sends the call to the other EJB, including the Xid
7. Receiving end creates a TX object with the Xid as id
8. Receiving end calls TM.resume(daTx). The tx is now associated with
the tx. Another thread; same tx
9. Call is forwarded to instance.
10. Business logic. Blah
11. Instance is finished and call returns. Tx is suspended. Tx does, yet
again, not have a "home"
12. Stub to EJB gets the return value and resumes the previously
suspended tx
13. Stub returns value to the EJB instance that called it
14. First EJB instance returns
15. EJB-call commits tx
NOTE: The first execution thread is also SUSPENDED (per normal RMI
semantics) at 6. The thread CANNOT be used for another call until this
one has finished.
So, if 4 were to only extract the Xid, and not disassociate the thread
with the tx, then there would be *2* threads at 8 associated with the
*same* TX!! (the one with Xid). That seems to be what you are
suggesting, and is what I don't understand. How can several threads be
associated with the same tx at the same time without causing trouble?
> got it?
Not quite. Explain what is wrong with the above first.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
