Ole,
Also I was rereading your first mail where you describe the work you have
done and I want to apologize. I am a bit of a dick for focusing JUST on the
spot where I don't agree... frankly I believe you have done an outstanding
job and encourage you to keep it up, these points we are discussing are
frankly almost details compared to the work you have already done.
My apologies for being a pain :)
(feel free to keep the discussion going or kill it :)
again bravo for your outstanding work on the TM, Please commit asap under a
new module for the JBossTM project.
Regards
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
|Sent: Wednesday, February 07, 2001 11:07 AM
|To: jBoss Developer
|Subject: RE: [jBoss-Dev] Upcoming TM changes
|
|
||I think you are wrong here.
||Quoting JTA 1.0.1 specification, section 3.2.3:
||"A call to the TransactionManager.suspend method
||temporarily suspends the transaction that is
||currently associated with the calling thread.
|
|Ok the spec makes no sense :)
|
|Ok that sentence says nothing about "disassociation" but "suspend the
|transaction" . The action is to "suspend" the target the
|transaction. Which
|one? the one that you can retrieve from the thread association.
|
|We don't know what the "suspend" operation is, and it doesn't say anything
|about disassociation, however (see below)
|
||If the thread is not associated with any
||transaction, a null object reference is returned;
|
|ok
|
||otherwise, a valid Transaction object is returned.
||The Transaction object can later be passed to the
||resume method to reinstate the transaction context
||association with the calling thread.
||The TransactionManager.resume method re-associates
||the specified transaction context with the calling
||thread. If the transaction specified is a valid
|
|This is inconsistent as the "suspend" and "resume" are not
|symetrical. This
|part ONLY talks about association and nothing about "resuming the
|transaction". SO that the action done on resume is "associate" thread, the
|action done on suspend is "temporaly suspend the transaction".
|
|Do you see the inconsistency.
|
||transaction, the transaction context is associated
||with the calling thread; otherwise, the thread is
||associated with no transaction."
||
||So thread association *is* done in these methods.
|
|No, in THIS method (resume) nothing is said in "suspend" in fact suspend
|cleanly says that it is a "TX" lifecycle event. The spec is non
|symetrical...
|
||Further quoting section 3.2.3:
||"The application server is responsible for ensuring
||that the resources in use by the application are
||properly delisted from the suspended transaction.
|
|Ok end of story. When I finish my invocation in the container I
|disassociate the thread that is going in because it could be reused for
|another invocation. THIS ISN"T A "SUSPENSION" and I CERTAINLY DON"T WANT
|THE JDBC DRIVER TO BE DELISTED, the JDBC driver should remain there since
|other threads associated with this transaction will commit/rollback at some
|point. Again suspend resume are methods that live in the realm of
|"transaction demarcation semantics" thread association doesn't.
|
|We must NOT properly delist the suspended transaction, because the
|call I am
|talking about from the container IS NOT A SUSPENSION OF THE TRANSACTION the
|transaction is STILL VERY ACTIVE, it is just a DISASSOCIATION of the thread
|to the Transaction.
|
||A resource delist operation triggers the Transaction
||Manager to inform the resource manager to
||disassociate the transaction from the specified
||resource object (XAResource.end(TMSUSPEND)).
||When the application s transaction context is
||resumed, the application server ensures that the
||resource in use by the application is again enlisted
||with the transaction. Enlisting a resource as a
||result of resuming a transaction triggers the
||Transaction Manager to inform the resource manager
||to re-associate the resource object with the resumed
||transaction (XAResource.start(TMRESUME))."
|
|That is fine that is the semantics of "suspend/resume" we argued and it was
|pointed out that there was no support for distributed "suspend/resume".
|
|End of story.
|
|Bottom line: JTA is at best misleading at worst poorly written.
|
||So JTA says that resource suspension/resumption
||is *not* the responsibility of the JTA
||implementation when suspending/resuming with
||TM.suspend()/TM.resume().
||
||But besides thread association suspension and
||resource suspension, what is in a tx suspension?
||IMO nothing.
|
|ah ah, well ok we don't agree there. In fact the "propagation" we are
|talking about does apply in a suspension.
|
|Again imagine the following scenario:
|
|You start a big transaction and you do work. Then you say "before
|I buy the
|car I want to talk to my wife" and so you tell the system "will decide
|later" what can teh system do? it can "suspend the transaction" so that the
|resource manager of JDBC to the bank approving the loan will not
|hold to the
|transaction and TIME OUT and ROLLBACK in 20 minutes. You clean up the
|resources enrolled in teh TX with this suspend call (if distribution, let's
|even assume "no distribution" it is irrelevant to the discussion). So you
|come back and you say "i buy" and it "RESUMES" the tx and enroll everybody
|so that the play can finish with everybody in a transactional aware state.
|
|Now if this was to take place at once? you would time out ...
|
|So what is disassociation? well imagine the stuff is done at once and the 3
|components talk in a container. First thread is going through
|then it calls
|another bean, when that bean is done it "disassociates" the thread because
|the bank bean is done with this work and moves on the next one, but the
|state is still part of the transaction (with a JDBC driver under it). THAT
|DISASSOCIATION (that happens 30 times a second) DOESN"T SUSPEND THE
|TRANSACTION, it just disassociates a thread in a corner of the application
|and transaction. The transaction goes on and commits. Never was there a
|"suspend transaction" demarcation in its life cycle.
|
|yes?
|
||But that leaves *only* thread association
||suspension/resumption to be done in the TM
||suspend()/resume() methods.
|
|yes,
|
|Since there isn't support for the scenario I put above, Ie a clear
|understanding of "suspend and resume" and propagation, there is no code to
|support that (and no interface to distribute it I understand). So
|it leaves
|Tx association and disassociation, yes. These can legally be different
|methods, I argue that they are since as shown above we disassociate
|INDENPENDENTLY of the suspend event in the lifecycle.
|
|
||> Well please answer clearly where I can associate the thread with the
||> transaction (we do that quite a lot in the containers, all the
||time, almost
||> every entity call)... ***HOW*** do you implement that call, with resume?
||
||Well, I haven't changed any of that code, but
||I would like the container to get rid of any
||non-JTA calls to the TM.
||
||J2EE-RI and JonAS use TM.resume() for this.
|
|"mal de muchos remedio de tontos" (spanish equivalent of "3 trillion flies
|eat shit so you too should")
|
|and it's a miss-interpretation of simple facts. JTA is buggy in its text,
|blame it on Susan cheung. It was an amazing piece of spec she was
|trying to
|put together in a hurry.
|
||In both cases, the code is a little hard to
||read because resource suspension/resumption
||is done in the JTA impl (JonAS), or in a
||layer on top of it (J2EE-RI). In neither
||case there is special thread association
||methods.
|
|I agree that the code to do it is a couple of lines if YOU DON'T DO THE
|PROPAGATION. Please go ahead and forget this discussion :)
|
|however
|
||
||But if JTA TM suspend()/resume() do thread
||association only as I am arguing, it would
||not be that bad to use this, would it?
||
|
|it would be bad. A properly implemented suspend will disenlist the
|resources... that is wrong.
|
|
|The only reason it works is because we don't implement 3.2.3 properly. If
|the implementation as you claim you did it, doesn't do that
|propagation then
|it is innocuous. A properly implemented TM will disenlist the
|JDBC driver I
|was talking about and when your container calls commits, since the JDBC
|driver isn't listening on the TX demarcation, and you have killed part of
|teh state of your TX.
|
|yes?
|
|marc
|
|
|
||Best Regards,
||
||Ole Husgaard.
||
|
|
