I'm hearing this message from a couple of different sources.
----- Original Message -----
From: "John Harby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 10:28 AM
Subject: Re: Entity Beans
The architect of the VM for HP once said in a meeting that
the worst performance problem they were seeing overall was
lock contention.
>From: Gene Chuang <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Entity Beans
>Date: Thu, 1 Mar 2001 09:56:56 -0800
>
>Rickard and Lawrence,
>
>Rickard is right; with modern JVM (>= 1.3)and HotSpot 2.0, object creation
>and GC are performance red herrings.
>
>I have done extensive load-generating profiling of our architecture. We a
>lot of our entity beans are fine-grained (1 bean = 1 row) and represent
>nodes in giant tree structures. Even with the potential to create an
>overwhelming amount of objects (beans), our application spends over 80% of
>the time hitting the database, which leaves 20% of our application up-time
>in Java land. And of this 20%, I would say a good 18% is spent on actual
>intense processing, which leaves roughly less than 2% on background noise
>(object creation, GC, etc...).
>
>Gene
>
>
>-----Original Message-----
>From: A mailing list for Enterprise JavaBeans development
>To: [EMAIL PROTECTED]
>Sent: 3/1/01 6:03 AM
>Subject: Re: Entity Beans
>
>Disclaimer: This is a tricky subject, and I do not in any way claim to
>have the final answer on this one.
>
>Now, on with the show..
>
> > What you say is true, but I thought the main savings were in object
>creation
> > and garbage collection. That is why stateless session beans (which
>normally
> > will have no state whatsoever) are pooled isn't it?
>
>Well, a year ago that might have been true, but now I'm not so sure,
>since doing manual object pooling in Java code might actually counter
>the memory management algorithms of modern JVMs. This is what I have
>been told anyway (by JRockit engineers).
>
>So, if this is actually true, then there would be no point in doing
>pooling of stateless session beans either. Just instantiate as needed,
>and don't bother with it. I have no problem seeing why this could be
>true, but I haven't done any extensive testing of this.
>
>Again, though, this assumes that setEntityContext is cheap. If you have
>a case where that callback actually does heavy operations, then all bets
>are off, or at least the above reasoning.
>
>regards,
> Rickard
>
>--
>Rickard Öberg
>
>Email: [EMAIL PROTECTED]
>
>========================================================================
>===
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
