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: David Jencks <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Thanks for the update. Can you let me know which hashmap in
C
> 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
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 (whatever
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 (whateve
>
> 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 r
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 y
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 beginnin
04:38 PM, Stefan Reich wrote:
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
Subje
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)
> 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. I
y 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()
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
> -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?
>
>
> >
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
> > 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
De : [EMAIL 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 resume
> > * 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 LIFECYCL
> -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
e sky)
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]De la part de
> Stefan Reich
> Envoye : samedi, 25 janvier 2003 02:24
> A : [EMAIL PROTECTED]
> Cc : [EMAIL PROTECTED]
> Objet : [JBoss-dev] Re: how's ecperf going?
>
>
> Hi Bi
> * JAWS checks for the existence of a PK before inserting a new row in
> the database. This is pretty expensive.
There is a patch for skipping the PK test [636794].
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM
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,
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 versi
22 matches
Mail list logo
