This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
However the containers chose to cache the entity beans as well
I am wondering what do you mean by chose to cache.... Since the pool is must, what do you think the container could use it otherway ?
Joined: Feb 17, 2005
The answer to your question is not very short, but I�ll do my best to make it short. A straight answer would be this: because the container implements a lot of feature that are beyond the J2EE specs: caching entity beans between transactions (and reducing the number of ejbLoad()/ejbStore() method calls), providing read-only EJBs, etc. Therefore the container will chose to implement a cache of entity beans as well. Please don�t understand me wrong: the container will not replace the free pool with an internal cache; this techniques are complementary not exclusive. However there is a big difference between the pool and the internal cache. The cache will contain only READY instances: they have identity (an associated primary key), but are not currently enlisted in a transaction. WebLogic maintains READY entity EJB instances in least-recently-used (LRU) order. If the bean gets enlisted in a transaction then the instance becomes ACTIVE and will return to cache after the transaction ends. As you can see there is a lot of stuff beyond the specs� Regards.