Interactions

ResourcePool and PooledResource cooperate to manage and recycle ConcreteResources on behalf of client code. Figure 6.2 shows what happens when a client requests a Resource from an empty ResourcePool. The ResourcePool discovers that it has no existing Resources available so it creates a new ConcreteResource and decorates it with a PooledResource. ResourcePool returns the PooledResource to the client.

The PooledResource delegates all operations to its referenced ConcreteResource. The only exception is for the close operation. When the client calls close, the PooledResource intercepts each call and puts the ConcreteResource into the ResourcePool for recycling. Figure 6.3 shows this interaction:

Figure 6.4 portrays a subsequent getResource operation. Now that the ConcreteResource is checked back into the ResourcePool, the ResourcePool can recycle it. The next time the client calls getResource, the ResourcePool removes this ConcreteResource from the pool and decorates it with a PooledResource.

A side-effect of leaving ConcreteResources open is that clients can potentially use them even after returning them to the ResourcePool. When this happens, multiple processes share the same ConcreteResources. This condition can in turn lead to inconsistent results and concurrency problems that are difficult to diagnose. ResourcePool creates a new PooledResource decorator for every request as a precaution to prevent this possibility. PooledResource maintains its own closed state. Once it has returned its ConcreteResource to the pool, it rejects any subsequent operations.