NAME

SYNOPSIS

 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

DESCRIPTION

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.

EXAMPLES

 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 >)

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 > and > 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.

TIMEOUTS

Imagine a situation where you have a newly created ResourcePool for a database (without >) 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 > are only minimum values. If you configure a > 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...

LIMITATIONS

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 > 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.

SEE ALSO

AUTHOR

    Copyright (C) 2001-2009 by Markus Winand <mws@fatalmind.com>

    This program is free software; you can redistribute it and/or
    modify it under the same terms as Perl itself.

POD ERRORS

Around line 115:

=back doesn't take any parameters, but you said =back So this call to L<get()|/get> would have taken about 7 seconds.