Usually one uses a DB connection-handle pooler: it keeps persistent handles for a short while for re-use, and re-establishes connections on demand. Much more efficient than doing it per-request. Look in CPAN.
Re: puzzling problem with access to DB when using mod_perl
Replies are listed 'Best First'.
Now, my question regarding this, becomes, which of the available options would you recommend? In addition to Apache::DBI, I have seen Class::DBI, Rose::DB::*, and DBIx::Class. And I am sure there are others that I haven't seen. According to what I have read so far, Rose::DB::* will use Apache::DBI if it is available (i.e.installed and loaded), but the others as far as I can tell would be competitors that do the pooling and more. But it is my understanding that each of these provide connection pool handling, and are thus competitors that do more. Are you aware of anyone who has done an objective comparison of the available options, looking at feature sets, relative performance, code maturity, &c.? It would be useful for guys like me to see such a review, in order to focus on studying those packages that will provide the biggest benefit for the time spent. NB: This isn't a question of which is better, but, rather, which provides the best fit to what a given developer is looking for (much as I would choose C++ for some applications and Perl for others, and Java for still others, depending on the problem domain).
Based on my research, including a post by the chap responsible for some of these packages, it would appear that Class::DBI and DBIx::Class are obsolete, and that if one is to use a Perl ORM , one should use Rose::DBI::*. That said, if the objective is primarily speed, the benchmarking page I found for Rose::DB::* would suggest that though it is much faster than any other ORM tested, one is still better off using DBI itself.
I do not know if the benchmark tests used are inadequate to show the benefits of using an ORM, or if ORM systems are just a convenience for developers that may or may not justify the poorer performance (the cost of development is, after all, a major consideration alongside the speed of an application, when deciding what to do to support the functional requirements defined for the application). I will thus study Rose::DB::*, and reserve judgement as to whether or not it's use is warranted at least in some circumstances. (Maybe someone with experience with it, or a similar ORM, would like to contribute some insight based on observations when using it in real world applications?)