Re: mod_perl, dbh, forked

there shouldn't be any issues with keeping a dbh in a modules' namespace for re-use by any methods in that module

Yes there should. Don't do that unless you're prepared to handle all the contingencies. Nearly everyone should be able to use Apache::DBI or DBI->connect_cached. If you need help with those, please ask.

What's the strange behavior you see when you fork? Just anomalies in your time logs, or something else?

One thing to watch out for is that many databases will call server-side cleanup routines when a dbh is closed or times out. You can control this with InactiveDestroy. You also typically need to open a new connection in the child, so if you're trying to keep using a connection opened in the parent, try making a new one instead.

Comment on Re: mod_perl, dbh, forked

Replies are listed 'Best First'.
Re^2: mod_perl, dbh, forked by Cagao (Monk) on Mar 07, 2008 at 20:26 UTC
Thanks for the advice... I was using Apache::DBI originally and prob took it out for all the wrong reasons... I use my own database object to hold 2 connections to 2 different databases, live and readonly, I put a warn statement in my database object and the logs went nuts when I restart apache, for example: 20 modules, each with 10 methods, each of which needs a dbh, starting 100 instances of apache means 20,000 connections! :-/ I used a global db object for each module so that each method only connected unless it was already connected (with the global dbh) I don't want to pass in 1 dbh from each handler since the handler shouldn't know where the objects are getting their data. No doubt I missed another possible approach? The other strange behaviour was a query that selected 3 rows from a table, putting warn statements in showed that i was passing the correct things to the sth->execute() that would work, but occassionaly $sth->fetchrow_hashref() returned { '1' => 1 }.	[reply]
Re^3: mod_perl, dbh, forked by perrin (Chancellor) on Mar 07, 2008 at 20:47 UTC
When you use Apache::DBI or DBI->connect_cached, they both keep a global cache of connections. They will not open a new one unless you use different parameters to open the connection, or the old connection has been disconnected. I haven't seen that fetchrow_hashref behavior before, but I don't actually use that method. If you don't have RaiseError turned on, definitely do that, since you may be missing errors earlier in the process.	[reply]
Re^4: mod_perl, dbh, forked by Cagao (Monk) on Mar 07, 2008 at 21:37 UTC
I've got RaiseError switched on but it's not showing anything anywhere, like I say, the bug I'm seeing is certainly odd and had a few of us in the office totally puzzled.	[reply]