In all of the other application servers I have been working on TransactionManager.resume() and suspend() are expensive operations, since the JTA spec version 1.0.1 (section 3.2.3) requires the TM to delist/enlist every resource that takes part in the transaction, which is costly. If it is done differently in Jboss on purpose, that's fine, I just wanted to make sure it's no oversight.

Stefan
On Monday, Jan 27, 2003, at 13:08 US/Pacific, Bill Burke wrote:

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of marc
fleury
Sent: Monday, January 27, 2003 11:17 AM
To: [EMAIL PROTECTED]; 'Stefan Reich'
Subject: RE: [JBoss-dev] RE: how's ecperf going?


yes, if you take a look at the code, before the switch
statement that distinguishes the cases between the different
transaction attributes, we start by a tx.suspend() and, a few
lines after, a tx.resume() if it was a REQUIRES tag for example, etc.
I know I wrote the original version of the code.

What I argued Nth times is that tx.suspend() should just be implemented
with

threadLocalVariable.set(null);

meaning that we disassociate the thread from the TX.

The event "thread dis-association" is not relevant to anyone else, not
even to the TX. The TX DOESN'T CARE that it is associated with n
threads or not.

Actually it MUST care. The TX needs to interrupt threads on a TX timeout.
But you're right about the performance irrelevance. There's nothing really
expensive going on, nor should there be.

Bill



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to