Re: [JBoss-dev] RE: how's ecperf going?

[Dain Sundstrom]

I completely agree that the extra suspend/ resume should not cause any performance degradation. The problem with that code it is fucking hard to read. Your stare at it for a while going what the fuck is he doing here and then you finally realize that they always suspend the tx at the beginning of the method. This code is much easier to read if you put an if/else in the outer most element and only touch the transaction if you have to. I made this change when messing around but never got to committing it. Unless there is a real measurable performance problem I think we should always favor readability and maintainability of code.

-dain

On Monday, January 27, 2003, at 05:40 PM, David Jencks wrote:

FWIW, I agree 100% with you on this marc

david jencks

On Monday, January 27, 2003, at 05:34 PM, marc fleury wrote:

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,

IT IS A BUG IN THE SPEC !!!!!

I am dead serious. Also all the discussion sucks and comes from the
name of the API. Suspend() and resume() look like they are Tx lifecycle
operations which require resource delisting??? NO NO NO, resume and
suspend in the scope of what we do in the method is PURELY THREAD
ASSOCIATION, the TX goes on.

In our code it means "resume association" "suspend association" not
"suspend TX".

I had called it "dissassociateThread()" and "associateThread()" to
<emph> the fact that all we are looking for is "association of thread to
TX" and THAT'S IT. It was changed in subsequent impls. You are
talking about something else, you are talking about the notion of
"suspending THE TRANSACTION".

Do we have a line?

marcf

"Doesn't anyone else see this?
I feel like I am taking crazy pills"
-- ZooLander --




-------------------------------------------------------
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

-------------------------------------------------------
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