Object Pooling

As it has been mentioned several times in the previous sections, EJB containers can use object pools to keep from having to create new enterprise bean instances when a client asks for one. The container has the flexibility to create instances ahead of time and put them into a pool of ready objects. When a client invokes a create method on a home interface, the container may pull an instance from the pool and call a few service methods on the instance to prepare it and then allow the instance to be used by the client. The service methods depend on the type of enterprise bean, but usually include giving the enterprise bean an EJBContext object, which gives the enterprise bean access to the container's runtime environment. When a client calls one of the remove methods, the instance may be placed back into the pool so it can be reused for another client.

This is a very common pattern for optimizing performance of regularly used resources. By using an object pool, the container does not continue to create new instances of objects and then have to garbage collect them later. It maintains the life cycle of these beans to save performance and cleanup. You as a bean provider do not need to be concerned with this behavior, except to understand there is really no connection between when a create method is called and when the container performs a newInstance call on an enterprise bean.