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".
