Interesting topic :)

Why don't you ping the handle got from the pool before serving it? If you plan to run this code for long time, it is possible that stored handles won't work (morning bug or other failures).

Apache::DBI uses the ping technique, and so (i presume) does ResourcePool; from its docs:

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.

but I haven't tried it yet. I don't know if it provides some sort of parachute, like the one from the previous module:

In order to avoid inconsistencies in the database in case AutoCommit is off and the script finishes without an explicit rollback, the Apache::DBI module uses a PerlCleanupHandler to issue a rollback at the end of every request.

Why are you wrapping every call to the original object? I did some experiments with connection pooling storing db handles at class level and I never thought about wrapping every call; it seems simpler to me to handle exceptions locally.

Ciao, Valerio