On Wed, Apr 29, 2009 at 02:30:59AM -0000, Greg Sabino Mullane wrote: > > > > I'm curious if this is a smart approach for a very database-heavy > > site, or if this might be a hold-over from the "morning after" problem > > where site that were quiet all night would fail in the morning as > > their connections had timed out. > > It's a bad strategy no matter what the reasoning. Applications should > simply do things as normal and handle exceptions in a sensible matter.
I agree. And just because the ping to the database works (the simple select) doesn't mean the next request(s) won't fail. And by handling exceptions in a sensible matter means an eval wrapper high enough up in the application to catch every database exception and then determining which exception would indicate that a new $dbh should be created, right? Again, I wonder if the initial reason for the ping wasn't to deal with low traffic sites where the database connection might actually time out from inactivity. Otherwise, why bother pinging first when the actual request would fail? I suppose another reason might be if a ping fails you can attempt to reconnect and then continue on with the request. But, if an actual query or update throws an exception you can't really retry it. What I'm getting at is if you have AutoCommit on and you do an update that throws an exception can you be sure that the update didn't happen? (That's going to seem like a dumb question once I get some coffee.) BTW -- DBI's connect_cached() method does a ping. I suspect connect_cached() is used in plenty of busy applications. -- Bill Moseley. [email protected] Sent from my iMutt
