Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Are connections automatically pooled when using mod_perl?

by PerlOnTheWay (Scribe)
on Dec 19, 2011 at 08:26 UTC ( #944218=perlquestion: print w/replies, xml ) Need Help??
PerlOnTheWay has asked for the wisdom of the Perl Monks concerning the following question:

Are database and memcached connections automatically pooled for reuse when using mod_perl?

Or do we need to pool the connections explicitly?If yes, how is that done?

  • Comment on Are connections automatically pooled when using mod_perl?

Replies are listed 'Best First'.
Re: Are connections automatically pooled when using mod_perl?
by Anonymous Monk on Dec 19, 2011 at 08:43 UTC

    No, nothing is automatic

    If you're using Apache::DBI, you're getting cached connections, whether or not you're using DBI->connect_cached

    Read Apache::DBI, much of the information carries over to how to accomplish said task for memcached

      How is that done for memcached?

      I don't find a Apache::Memcached module exists..

        I would do it the same way as Apache::DBI does, except that instead of calling DBI->connect, I would set up the connection to memcached. It shouldn't be hard if you work from Apache::DBI. ->pinging the connection might be a bit more difficult.

Re: Are connections automatically pooled when using mod_perl?
by jdrago999 (Pilgrim) on Dec 19, 2011 at 18:20 UTC

    In a mod_perl environment, your variables (like database handles) can live longer than a single request if you declare them in a scope "outside" of the request.

    For example:

    package MyHandler; use strict; use warnings 'all'; use Apache2::RequestRec; use Apache2::RequestUtil; # Declare it here: my $persistent_thing; sub handler : method { my ($class, $r) = @_; # The first time this is executed in a child process, it will be cre +ated. # After that, you will just reuse the same one: $persistent_thing ||= make_the_thing(); } 1;

    Please also check out Ima::DBI::Contextual as it solves the whole thing.

    package MyDBI; use base 'Ima::DBI::Contextual'; my @dsn = ( 'DBI:mysql:dbname:hostname', 'username', 'password', { # Other options go here: RaiseError => 1, }); __PACKAGE__->set_db('Main', @dsn); 1;

    Then, elsewhere:

    use MyDBI; # Automatically pooled and recreated if the old one times out or dies: my $dbh = MyDBI->db_Main;
      FYI, FWIW, AFAIK, technically, neither Apache::DBI nor Ima::DBI::Contextual provide an actual pool , they merely provide a cache. The Apache::DBI docs explain this explicitly and in detail. The Ima::DBI::Contextual are more funny than informative :)

        The Ima::DBI::Contextual (docs) are more funny than informative :)

        You're right. That should probably be fixed.

Re: Are connections automatically pooled when using mod_perl?
by leuchuk (Novice) on Dec 19, 2011 at 16:30 UTC

    The answer is in my opinion incomplete.

    If you use PostgreSQL then pooling is enabled just with some piece of additional software. So if you really want to use a Perl-only solution this software (or may be Apache, but I'm not too competent on this question) would have to do it all by itself.

Re: Are connections automatically pooled when using mod_perl?
by sundialsvc4 (Abbot) on Dec 21, 2011 at 12:34 UTC

    Like all forms of persistent CGI handling, a mod_perl app handles many requests during its lifetime and can therefore simply keep a DBI-handle open all the time.   Sometimes this is the best way to handle it; it certainly is the simplest, e.g. if you have only one database that you need to connect to.

    But otherwise, if you need connection pooling, you need to use any one of several available CPAN modules to do it.   (For example, DBIx::Connector.)   IMHO, these would probably come into play when there are several databases to which you need to maintain connections, some being used more frequently than others and/or some having a very high demand for connections.

    If you are in this “very high demand” situation, then perhaps consider a client/server arrangement in which workers, instead of seeking the information themselves, post an asynchronous request for that information to another service process (or pool of the same).   A backlog in a queue of requests can be serviced in constant time regardless of the momentary length of the queue, whereas a backlog of “too many cooks in the kitchen” can result in suddenly-exponential performance degradation curves similar to that of virtual memory “thrashing.”   But, this is a fairly fundamental change in design philosophy, away from a tight-knit monolithic application to a loosely-coupled system of cooperating applications; not merely database connection pooling.

    A less-intrusive notion is to introduce the idea of “a counting semaphore,” in which processes must acquire the semaphore before obtaining a connection or what-have-you and only n processes may simultaneously do so.   Like taking a number at the meat-counter in the grocery store.   Some, but not all, implementations of what they call “pooling” do that.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://944218]
Approved by Corion
Front-paged by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (8)
As of 2017-09-26 06:05 GMT
Find Nodes?
    Voting Booth?
    During the recent solar eclipse, I:

    Results (292 votes). Check out past polls.