StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POShould I disconnect() if I'm using Apache::DBI's connect_cached()?
text
Body
copied!<p>My mod_perl2-based intranet app uses <code>DBI->connect_cached()</code> which is supposedly overridden by <code>Apache::DBI</code>'s version of the same. It has normally worked quite well, but just recently we started having an issue on our testing server--which had only two users connected--whereby our app would sometimes, but not always, die when trying to reload a page with 'FATAL: sorry, too many clients already' connecting to our postgres 9.0 backend, despite all of them being <code><IDLE></code> if I look at the stats in pgadmin3.</p> <p>The backend is separate from our development and production backends, but they're all configured with <code>max_connections = 100</code>. Likewise the httpd services are all separate, but configured with</p> <pre><code>StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 99 MaxClients 99 MaxRequestsPerChild 4000 .... PerlModule Apache::DBI </code></pre> <p>I had been under the impression that I shouldn't call <code>disconnect()</code> on my database handles if I wanted them to actually benefit from caching. Was I wrong about that? If not, I guess I'll ask about the above error separately. Just wanted to make sure it wasn't this setup...</p> <p><a href="http://search.cpan.org/~phred/Apache-DBI/lib/Apache/DBI.pm" rel="nofollow">Apache::DBI's docs</a> say:</p> <blockquote> <p>When loading the DBI module (do not confuse this with the Apache::DBI module) it checks if the environment variable 'MOD_PERL' has been set and if the module Apache::DBI has been loaded. In this case every connect request will be forwarded to the Apache::DBI module. .... There is no need to remove the disconnect statements from your code. They won't do anything because the Apache::DBI module overloads the disconnect method.</p> <p>If you are developing new code that is strictly for use in mod_perl, you may choose to use DBI->connect_cached() instead, but consider adding an automatic rollback after each request, as described above.</p> </blockquote> <p>So I guess for my mod_perl2-only app, I don't need Apache::DBI because Apache::DBI's devs recommend using DBI->connect_cached. And I don't need disconnect statements.</p> <p>But then <a href="http://search.cpan.org/~timb/DBI-1.630/DBI.pm" rel="nofollow">DBI's docs</a> say:</p> <blockquote> <p>Note that the behaviour of [ connect_cached ] differs in several respects from the behaviour of persistent connections implemented by Apache::DBI. However, if Apache::DBI is loaded then connect_cached will use it.</p> </blockquote> <p>This makes it sound like Apache::DBI will actually affect connect_cached, in that instead of getting DBI->connect_cached behaviour when I call that, I'll get Apache::DBI->connect behaviour. And Apache::DBI's docs recommend against that.</p> <p>UPDATE: I've set the first 5 parameters in the above config all to 1, and my app is still using up more and more connections as I hit its pages. This I don't understand at all--it should only have one process, and that one process should be re-using its connection.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload