Both caches and pools are used in J2EE environment.
A pool is a collection of stateless objects. Eample – database connection pools, thread pools, and Servlet pools.
A cache is a collection of stateful objects. Example – Entity Bean caches and Stateful Session Bean caches. Aside from Entity Beans and Stateful Session Beans, caches are useful to hold any data that you want to look up once and reference it multiple times, things like JNDI entries, RMI services, configuration file contents, etc. Caches save time!
The main distinction between a cache and a pool is what is contained in them. In other words: when you retrieve an object from a cache or a pool, do you need a specific object, or will any object do? If you need a specific object, then each object maintains state; hence, you need to use a cache. If, on the other hand, you can use any object, then the objects do not maintain state and you can use a pool.
Let’s compare their performance considerations:
- A request for a pooled object can be serviced by any object in the pool.
- A request for a cached object can only be serviced by a specific object in the cache.
- If all objects in a pool are in use when a request is made, then the request must wait for any object to be returned to the pool before the request can be satisfied.
- If the requested object in a cache is in use when it is requested, then the request must wait. It doesn’t matter if the rest of objects in the cache are available, as a specific one is needed.
- The size of a pool can be fixed or can grow. If a new object is requested from an empty pool, a new object can be created and added to the pool.
- The size of a cache is usually fixed (because it holds specific objects and creating a new one is not always an option). However, if the cache is full and a new object needs to be loaded into the cache, an existing object has to be removed from the cache (activation and passivation).
Full Article is at: http://www.informit.com/guides/content.asp?g=java&seqNum=104&rl=1