Re^2: mod_perl, dbh, forked

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 }.

Comment on Re^2: mod_perl, dbh, forked

Replies are listed 'Best First'.
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]