The object pool design pattern was designed for performance optimization. The motivation behind pools is to avoid to constantly create new instances of required objects and dependencies, by retaining them in a pool of objects for a longer period of time. A required instance is retrieved from this pool of objects and released after usage.

This concept is already built into Java EE containers in different forms. As mentioned earlier, stateless session beans are pooled. This is the reason why they perform exceptionally well. However, developers have to be aware of the fact that instances are being reused; instances must not retain any state after they have been used. The container keeps a pool of these instances.

Another example is the pooling of database connections. Database connections are rather expensive to initiate and it makes sense to keep a few of them alive for later use. Depending on the persistence implementation, these connections are reused once a new query is requested.

Threads are also pooled in enterprise applications. In a Java server environment, a client request typically results in a Java thread that handles the logic. After handling the request, the threads will be reused again. Thread pool configuration as well as having different pools is an important topic for further performance optimization. We will cover this topic in Chapter 9, Monitoring, Performance, and Logging.

Developers won't typically implement the object pool pattern themselves. The container already includes this pattern for instances, threads, and databases. The application developer implicitly uses these available features.