Larry Allen wrote: >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. The pools in EJB are not only for reducing the number of memory allocations. The ability to limit/adjust resource usage in a server is the secret behind the server's scalability. The various instance pools in an EJB server allow you to fine tune/balance the overall server for a specific configuration of resources. It is again a question of resource management. Without pools (or their functional equivalents) we cannot talk about scalable servers. Imre Kifor Valto Systems >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".
