|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
To start out, let's review an interface to a generic resource pooling system that has been reduced to its essence. This interface is simply a generic description of a pool that can contain objects of any type. The object being pooled is referred to as the resource. Examples of resources might be database connections, socket connections, or available phone lines. Here's the interface:
public interface ResourcePool
{
public Object getResource();
public void releaseResource(Object resource);
}
When a resource, such as a database connection, is required, we do not create the object within the client code. Instead,
we go to the resource pool and call the getResource() method, which returns one of the available objects within the pool. Normally, the objects in the pool have been created (instantiated)
in advance. When we have finished with the object, we must return it to the ResourcePool. Note that, if all the users of a resource pool are not well-behaved code citizens, doing their job and returning the object
to the pool, the benefits of the pooling model are broken, and we would be better off without it. So, as good clients of the
pool, when we take an object out, we make a vow that we will put it back some time in the future.
It is quite possible that implementations of this interface will use a FactoryMethod to create the resource objects when the object pool is first created; this allows the pooling mechanism to be decoupled from
the logic of creating the objects. The implementations could also use a lazy instantiation (as shown in Java Tip 67) to create a resource when all the currently constructed resources are in use.
For example, some resource pool implementations have a MAX and MIN capacity. When this type of pool is first instantiated, it creates the MIN number of resources, but as the number of requests exceed MIN, the pool creates more objects on demand by means of lazy instantiation until it reaches MAX.
The generic object pool can be configured at runtime to contain any type of resource. We may choose to do this by using factory objects in the concrete implementation of the resource pool. In this case, the factory object is responsible for creating the type of resource within the pool and may be hidden completely from the clients of the resource pool interface.
If you want to delve deeper into an implementation of a resource pool take a look at Thomas E. Davis's article, "Build your own object pools." For the moment, let's take a look at extending the interface to cope with objects that become broken while we are using them.