Great comment!
Depending the type of garbage collection being used and the amount of
activity on the system, your point may or may not be valid.
Creating new objects requires that space be allocated in memory and may also
require that work be done by the garbage collector (marking a reference
alive for example). With each object creation, cycles are needed to allocate
space and perform other activities. When a bean instance is destroyed, the
time required to perform garbage collection is increased. This is
compounded when bean instances have a large object graph. It's these costs
that are offset by pooling. (That and the cost of resource allocation).
For really big systems where thousands of beans are used concurrently, the
cost of creating and garbage collecting all the bean instances needed, can
become a real bottleneck to performance. Maintaining a small pool of bean
instances that can service many clients can offset this bottleneck.
It would be great to hear more on this from the vendors. I know that some
use pooling while other do not
Richard
-----Original Message-----
From: Larry Allen
To: [EMAIL PROTECTED]
Sent: 3/18/99 4:02 PM
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".
