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.
