perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Gormley <cl...@traveljury.com >
Subject Re: Confused Apache::DBI (best practice)
Date Tue, 17 Jul 2007 10:31:02 GMT
You should not share connections between processes.  You will end up
with segfaults.

The way Apache::DBI works is as follows:
 - you connect and disconnect from the DBI as per normal
 - Apache::DBI caches your connection and overrides disconnect
   so that it doesn't actually disconnect
 - when you request a new connection, it checks for a cached
   connection with the same connection parameters. if one exists,
   it does a ping to ensure that it is still alive, and returns it.
 - otherwise, it creates a new connection and returns that

As long as you are using the same connection parameters for all your DB
connections, you will only have one connection per apache child. Oracle
can handle this with ease.

If you have different users with separate connections to the DB, then
Apache::DBI probably isn't what you want to use, as then you will end up
with a separate connection for each user in each process.  however, this
is not the normal scenario. Most websites only need one or two unique
connections per process.

Clint

On Tue, 2007-07-17 at 10:36 +0100, Anthony Gardner wrote:
> I'm a little confused over the use of Apache::DBI or using DBI's
> connect_cached.
> 
> I always thought that Apache::DBI would allow me to use one connection
> through multiple processes, but that seems to be not true. After
> reading the docs more thoroughly , it seems as though one handle can
> not be shared by each process at server startup and the connections
> are persistent on a per process level.
> 
> At server startup, through the use of Apache::DBI, I start with an
> initial 8 processes and the DB (v$session) shows 8 connections. Under
> stress testing, we run out of connections :(
> 
> Some debug during server startup ....
> [snip]
> 28668 Apache::DBI             PerlChildInitHandler
> 28668 Apache::DBI             need ping: yes
> 28668 Apache::DBI             new connect to '******^\/^\^
> \AutoCommit=1^\PrintError=1^\Username=/'
> [/snip]
> 
> The processes that were created during startup use the same hash
> as ...
> 
> ......... running the application
> 
> [Tue 07 17 11:03:52 2007][PID 28668 PCE::DBI::Helper::connect
> 39 ][DEBUG] DBH Apache::DBI::db=HASH(0xa89f414)
> [Tue 07 17 11:03:52 2007][PID 28666 PCE::DBI::Helper::connect
> 39 ][DEBUG] DBH Apache::DBI::db=HASH(0xa89f414)
> 
> When a new process is created ...
> 28727 Apache::DBI             new connect to
> '******/AutoCommit=1PrintError=1Username=/'
> 
> and later used ...
> 28727 Apache::DBI             need ping: yes
> 28727 Apache::DBI             already connected to
> '******/AutoCommit=1PrintError=1Username=/'
> 
> [Tue 07 17 11:10:05 2007][PID 28727 PCE::DBI::Helper::connect
> 39 ][DEBUG] DBH Apache::DBI::db=HASH(0xa89f414)
> 
> It uses the same hash. But, this isn't always the case. Under stress
> testing, new hashes have been created.
> 
> So, my question is, how do I not bring my system to a grinding halt
> with runaway connections? There will be more than one DB instance
> running on this machine, too. 
> 
> I've seen some stuff on perlmonks but mostly people talk about using a
> singleton (which I believe Apache::DBI is already doing).
> 
> We're using Oracle DB and  Apache/2.2.4 (Unix) mod_ssl/2.2.4
> OpenSSL/0.9.8e mod_perl/2.0.3 Perl/v5.8.8
> 
> Any advice would be great.
> 
> CIA
> 
> -Ants
> 
> 
> 
> ______________________________________________________________________
> Yahoo! Mail is the world's favourite email. Don't settle for less,
> sign up for your free account today.


Mime
View raw message