: 1
Date: Fri, 24 Jan 2003 21:13:19 -0500
Subject: Re: [JBoss-dev] Re: how's ecperf going?
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Thanks for the update. Can you let me know which hashmap in
CachedConnectionManager is causing contention?
Also, I have
Agreed. In this case there is a strong performance reason to
split the
code into two interceptors:
The point is that the call in the interceptors is JUST dissaciation and
association. The mumbo jumbo we are talking about (whatever it means to
suspend and resume a transaction) is not
On Tuesday, January 28, 2003, at 10:07 AM, marc fleury wrote:
Agreed. In this case there is a strong performance reason to
split the
code into two interceptors:
The point is that the call in the interceptors is JUST dissaciation and
association. The mumbo jumbo we are talking about
On Tuesday, January 28, 2003, at 09:07 AM, marc fleury wrote:
Agreed. In this case there is a strong performance reason to
split the
code into two interceptors:
The point is that the call in the interceptors is JUST dissaciation and
association. The mumbo jumbo we are talking about
We already agreed with you that in one vm
association/dissociation are
essentially free and if they aren't it is a bug. I'm saying that
oh ok :) sorry jumpy. yes association dissociation should be clearly
exposed JTA calls. Spec bug.
importing a tx when you don't need to is NOT free
* TxInterceptorCMP suspends and resumes a transaction in all cases,
sometimes even twice. This can be very expensive, especially with
global transactions.
?? Can you point this out?
for the nth time we are having this discussion.
NO, the 'suspend/resume' is NOT A LIFECYCLE EVEN ON
PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de marc
fleury
Envoye : lundi, 27 janvier 2003 16:52
A : [EMAIL PROTECTED]; 'Stefan Reich'
Objet : RE: [JBoss-dev] RE: how's ecperf going?
* TxInterceptorCMP suspends and resumes a transaction in all cases,
sometimes even twice. This can be very
PROTECTED]; 'Stefan Reich'
Objet : RE: [JBoss-dev] RE: how's ecperf going?
* TxInterceptorCMP suspends and resumes a transaction in all
cases, sometimes even twice. This can be very expensive,
especially with global transactions.
?? Can you point this out?
for the nth
I am all for it. The more people run Ecperf on various platforms and
JDKs, the better for the quality.
Stefan
Message: 6
From: Sacha Labourey [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Re: how's ecperf going?
Date: Sat, 25 Jan 2003 11:45:58 +0100
Reply
-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
It's the Map objectToConnetionManagerMap. I moved some null checks
out of the synchronized blocks, but there is not much more to optimize.
I'll check the changes in when I have the time.
Stefan
Message: 1
Date: Fri, 24 Jan 2003 21:13:19 -0500
Subject: Re: [JBoss-dev] Re: how's ecperf going
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
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
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)
:
It's the Map objectToConnetionManagerMap. I moved some null checks
out of the synchronized blocks, but there is not much more to
optimize. I'll check the changes in when I have the time.
Stefan
Message: 1
Date: Fri, 24 Jan 2003 21:13:19 -0500
Subject: Re: [JBoss-dev] Re: how's ecperf going?
From
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
On Monday, January 27, 2003, at 08:03 PM, Dain Sundstrom wrote:
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
-Original Message-
From: Stefan Reich [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 24, 2003 8:24 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: how's ecperf going?
Hi Bill,
I am running ecperf regularly on the 3.0 and 3.2 branches. I
accumulated a bunch of
Hi Bill,
I am running ecperf regularly on the 3.0 and 3.2 branches. I
accumulated a bunch of fixes for scalability and performance problems
already, plus a few fixes for inconsistent lock usage that I will merge
soon.
Here are some things I noticed:
* the test fails when I deploy the BMP
Thanks for the update. Can you let me know which hashmap in
CachedConnectionManager is causing contention?
Also, I have a plan for 4 anyway to only swap transactions when they
actually change. it should be pretty easy to fix in 3/3.2 directly
also.
thanks
david jencks
On Friday, January 24,
20 matches
Mail list logo
