use ResourcePool;
use ResourcePool::Factory;

my $factory = ResourcePool::Factory->new("arg1");
my $pool    = ResourcePool->new($factory, MaxTry => 3);

my $resource = $pool->get();  # get a resource out of the pool
#[...]                        # do something with $resource
$pool->free($resource);       # give it back to the pool

$pool->fail($resource);       # give back a failed resource

The ResourcePool is a generic connection caching and pooling management facility. It might be used in an Apache/mod_perl environment to support connection caching like Apache::DBI for non-DBI resources (e.g. Net::LDAP). It's also useful in a stand alone perl application to handle connection pools.

The key benefit of ResourcePool is the generic design which makes it easily extensible to new resource types.

The ResourcePool has a simple check mechanism to detect and close broken connections (e.g. if the database server was restarted) and opens new connections if possible.

If you are new to ResourcePool you should go to the ResourcePool::BigPicture documentation which provides the best entry point to this module.

The ResourcePool itself handles always exactly equivalent connections (e.g. connections to the same server with the same user-name and password) and is therefore not able to do a load balancing. The ResourcePool::LoadBalancer is able to do a advanced load balancing across different servers and increases the overall availability by applying a failover policy if there is a server breakdown.

Creates a new ResourcePool. It uses a previously created ResourcePool if possible. So if you call the new method with the same arguments twice, the second call returns the same object as the first did. This is even true if you call the new method while handling different Apache/mod_perl requests (as long as they are in the same Apache process). (This is implemented using the ResourcePool::Singleton class included in this distribution)

$factory

@Options

 MaxTry => 5 
 SleepOnFail => [0, 1, 2, 4] 

Returns a resource. This resource has to be given back via the free() or fail() method. The get() method calls the precheck() method of the according resource to determine if a resource is valid. The get() method may return undef if there is no valid resource available. (e.g. because the Max or the MaxTry values are reached)

Marks a resource as free. This resource will be re-used by get() calls. The free() method calls the postcheck() method of the resource to determine if the resource is valid.

Marks a resource as bad. The ResourcePool will throw this resource away and NOT return it to the pool of available connections.

Executes a ResourcePool::Command with a resource from this pool. The execute() method implements the Command design pattern from the GoF book "Design Patterns". This enables you to use the ResourcePool without using the get(), free() and fail() methods manually. Basically the execute() method obtains a resource from this pool by calling its get() method, then calling the execute() method of the supplied Command and releasing the resource afterwards.

The execute method will call die() if an error happened, therefore it's best practice to wrap it in an eval{} block.

The ResourcePool::Command::Execute documentation covers this in all the details and facets which are introduced by this pattern.

This section includes a typical configuration for a persistent Net::LDAP pool.

use ResourcePool;
use ResourcePool::Factory::Net::LDAP;

my $factory =  ResourcePool::Factory::Net::LDAP->new("ldaphost",
                 version => 2 );
$factory->bind('cn=Manager,dc=fatalmind,dc=com', password => 'secret');


my $pool = ResourcePool->new($factory, 
                MaxTry      => 5, 
                SleepOnFail => [0,1,2,4]
);

if ($something) {
   my $ldaph = $pool->get();

   # do something useful with $ldaph

   $pool->free($ldaph);
}

# some code nothing to do with ldap

if ($somethingdifferent) {
   my $ldaph = $pool->get();

   # do something different with $ldaph

   $pool->free($ldaph);
}

So, lets sum up some characteristics of this example:

There is only one connection

Even if $something AND $somethingdifferent are true, there is only one connection to the ldaphost opened if you run this script.

Connections are created on demand

If neither $something nor $somethingdifferent are true, there is NO connection to ldaphost opened for this script. This is very nice for script (or sub routines) which MIGHT need a connection, and MIGHT need this connection on some different places. You can save a lot of

if (! defined $ldaph) {
   # your connection code goes here
}

stuff.

It much more convenient to pass a single argument (e.g. $pool) to a function than passing all the credentials.

If you want to make sure that there is always a connection opened, you can use PreCreate => 1 (see PreCreate)

Covers server outages

As long as the ldaphost doesn't crash while you are actually using it (between get() and free()) the ResourcePool would transparently cover any ldaphost outages which take less then 7 seconds.

You can easily change the time how long ResourcePool tries to create a connection with the MaxTry and SleepOnFail options. If you would have used MaxTry => 1000000 in the example above, the get() method could have blocked for about 46 days until giving up (after the first 3 tries it would have tried every 4 seconds to establish a connection).

If you have a connection problem with the resource while using it, it's the best practice to give it back to the pool using the fail() method. In that case the ResourcePool just throws it away. After that you can try again to get() a new resource.

No magic

The resources you obtain from the get() method are in no way magic. They are just plain Net::LDAP handles as you would create them yourself. You still MUST apply all the error handling when using this resource.

Examples for the execute() method can be found in the ResourcePool::Command documentation.

Time to say some more words about timeouts which take place in the get() method. As you have seen above you can configure this timeouts with the SleepOnFail option, but thats only the half truth. As the name of the option says, thats only the time which is actually slept if an attempt to obtain a valid resource fails. But there is also the time which is needed to try to obtain a valid resource. And this time might vary in a very wide range.

Imagine a situation where you have a newly created ResourcePool for a database (without PreCreate) and call the get() method for the first time. Obviously the ResourcePool has to establish a new connection to the database. But what happens if the database is down? Then the time which is needed to recognize that the database is down does also block the get() call. Thats usually not a problem if the operating system of the database server is up and only the database application is down. In that case the operating system rejects the connection actively and the connection establishment will fail very fast. But it's very different if the operating system is also not available (hardware down, network down,...), in this case it might take several seconds (or even minutes!!) before the connection establishment fails, because it has to wait for internal timeouts (which are not affected by ResourcePool). Another example is if your DNS server is down, it might also take a long time before the establishment fails. The usual DNS resolver tries more then one minute before it gives up.

Therefore you have to keep in mind that the timeouts configured via SleepOnFail are only minimum values. If you configure a SleepOnFail value of one second between the attempts, than you have a guarantee the there is at least a sleep of one second before the next attempt is done.

If you want to limit the overall timeouts you have two choices. 1. Use the timeout functionality of the underlaying modules. This is not always safe since the modules might use some functions which do not implement a configurable timeout or does just not use it. 2. Implement your own timeout using alarm(). Thats also not safe, since there is no guarantee that a blocking system call gets interrupted when a signal is received. But to my knowledge thats still the more reliable variant.

The best way of handling this timeouts is to avoid them. For a High Availability configuration it is important fail very fast to be effective. But thats easy to say...

Not transparent

Since the main goal of the ResourcePool implementation is to be generic for any resource types you can think of, it is not possible to implement features which need knowledge of the used resource types.

For this reason ResourcePool leaves you alone as soon as you have obtained a resource until you give it back to the pool (between get() and free() or fail()).

ResourcePool does not magically modify DBI or Net::LDAP to do a transparent reconnect if one connection fails while you are using it. The smartness of ResourcePool lies in the get() method, therefore you must keep the resources as short as possible outside of the pool and obtain a resource via get() if you need one.

But you have also to be careful to do too many get()/free() calls since this might also cause a overhead because of the precheck() and postcheck() methods.

Pools are not shared across different processes

The use of fork() and ResourcePool is only safe if there are no open resources (connections) when you are doing the fork.

Even if it sounds very invitingly to create a ResourcePool with some PreCreated connections and afterwards doing the fork, its just not save. Thats for several reasons: 1. There is no locking between the different processes (the same resource could be used more then once simultaneously). 2. There is no guarantee the the underlaying implementations do not keep some state-information locally (this could cause protocol errors). 3. It's impossible to share newly opened connection with the other processes.

If you try to pass some open resources through fork() you are alone! You will have some funny effects which will cost you a lot of time tracking down until you finally give up. And please, do not even think of asking for help as long as you do pass open resources through fork.

iThreads

Since perl 5.8 interpreter threads (iThreads) have become more popular. Even mod_perl 2.0 does massively use iThreads. So it would be great to share a ResourcePool across different iThreads. But this is not so simple: it would be possible to share the ResourcePool itself across iThreads, but to do the trick we also need to share the managed resources. So each resource you plan to use has to support shared handles. Non of the included resource types (Net::LDAP and DBI) do this yet. Therefore ResourcePool does currently not take any effort to share across iThreads. But thats for sure a major part on the TODO list.