EJB Container Settings
■Pool Idle Timeout: the maximum time that a stateless session bean, entity bean, or
If there are more beans in the pool than the maximum pool size, the pool drains back to initial and minimum pool size, in steps of pool resize quantity at an interval specified by the pool idle timeout. If the resize quantity is too small and the idle timeout large, you will not see the pool draining back to steady size quickly enough.
Tuning the EJB Cache
A bean in the cache represents the ready state in the EJB lifecycle. This means that the bean has an identity (for example, a primary key or session ID) associated with it.
Beans moving out of the cache have to be passivated or destroyed according to the EJB lifecycle. Once passivated, a bean has to be activated to come back into the cache. Entity beans are generally stored in databases and use some form of query language semantics to load and store data. Session beans have to be serialized when storing them upon passivation onto the disk or a database; and similarly have to be deserialized upon activation.
Any incoming request using these “ready” beans from the cache avoids the overhead of creation, setting identity, and potentially activation. So, theoretically, it is good to cache as many beans as possible. However, there are drawbacks to caching:
■Memory consumed by all the beans affects the heap available in the Virtual Machine.
■Increasing objects and memory taken by cache means longer, and possibly more frequent, garbage collection.
■The application server might run out of memory unless the heap is carefully tuned for peak loads.
Keeping in mind how your application uses stateful session beans and entity beans, and the amount of traffic your server handles, tune the EJB cache size and
EJB Cache Settings
An individual EJB component can specify cache settings that override those of the EJB container in the
The EJB cache settings are:
Chapter 3 • Tuning the Enterprise Server | 55 |
