>> So, what's saved by pooling? Two newInstances() and a
setEntityContext().
Almost. Can I add a third? The load on the gc. Minimizing lots of new's is
the name of the game in scalable Java server, right?
If you don't know me, lots = billions/day! I love my job.
David
Larry Allen <[EMAIL PROTECTED]> on 03/18/99 02:02:56 PM
Please respond to A mailing list for Enterprise JavaBeans development
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc: (bcc: David Rauschenbach/ZLAND)
Subject Re: FW: (TO SUN: please clarify) Re:
: ejbCreate( ) - initialize instan
ce variables
Jim Frentress wrote:
>
> i wish i could get off the fence on this one. in my opinion, you're both
> right.
Hmm. I've been thinking about this one for a while now, and I've come to a
somewhat radically different conclusion: I'm not convinced that there's
substantial benefit in pooling EJB bean instances.
Consider the relative cost of getting an instance from the pool vs. new'ing
up
an instance from scratch. In CMP, for example, if there is no pool, the
following sequence of events must happen when calling a business method on
an
Entity Bean:
- newInstance() call to the bean class
- new() of an EntityContext object
- setEntityContext() on the instance
- ejbActivate() call to the instance (N.B. it's not totally clear this is
required, but the spec seems to indicate that it is)
- read entity state from the database and load the container-managed
fields
- ejbLoad() call to the bean class
- and now we're ready to call the business method
Compared to the sequence of calls required for activating an instance from
the
pool:
- look up a free instance in the pool
- ejbActivate() call to the instance
- read entity state from the database and load the container-managed
fields
- ejbLoad() call to the bean class
- and now we're ready to call the business method
So, what's saved by pooling? Two newInstances() and a setEntityContext().
The
new() of the EntityContext object itself must be pretty cheap, as the
EntityContext object can't contain any information that's specific to the
bean
instance; setEntityContext() is usually a cheap operation. The new() calls
might be somewhat expensive, but this is something that's continually being
improved in the Java VM's. Any expensive initialization of the bean
instance's
fields must be done in the ejbActivate() (since, as this thread has pointed
out,
the bean can't depend on the container to initialize its non-persistent
fields). Finally, in most instances, all these costs will be dwarfed by
the
cost of reloading the instance's persistent state from the database anyway.
And, pooling adds cost and complexity to an implementation. Every pool
needs to
be managed (how many objects or what size should the pool be? How does the
LRU'ing work? How do objects get removed from the pool if a new version of
the
Entity Bean class is installed? etc.) The pool will probably have to be
synchronized, possibly becoming a point for thread contention on a large MP
system. The pool management in some sense is in conflict with the
operation of
the garbage collector, which works to make currently-unused objects
available as
free space for other (possibly non-EJB) uses; unused objects held in the
Entity
Bean pool use up memory (or address space) that could be used by these
other
uses.
I'm not debating that there could be some special cases in which Entity
Bean
instance pooling is a net gain in performance. And, certainly for those
cases
(e.g. object-oriented databases) in which the implementation can avoid
having to
reload the persistent state from the database, caching of instances can be
a big
win. But, for most cases, I don't see the gain.
-Larry Allen
SilverStream Software
===========================================================================
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".
