This is interesting...
Todd
-----Original Message-----
From: Gene Chuang [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 01, 2001 12:57 PM
To: [EMAIL PROTECTED]
Subject: Re: Entity Beans
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".
===========================================================================
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".
