On Fri, Oct 2, 2009 at 7:40 PM, David E. Wheeler <da...@kineticode.com>wrote:
> On Oct 2, 2009, at 9:30 AM, Kurt Hansen wrote: > > I'm wondering what techniques folks are using to get persistent database >> connections other than Apache::DBI. >> > > I plan to release a new module, DBIx::Connection, on Monday. It's based on > the connection caching stuff in DBIx::Class, and also has some nice > transaction management stuff, so you might want to [check it out]( > http://github.com/theory/dbix-connection/). > Hi David, This looks nice. Thanks. I don't use Apache::DBI, but this will be good for general connection and transaction support. I simply use connect_cached now with { privite_pid = $$ } but that doesn't allow me to set InactiveDestroy (although I'm not using $dbh in Apache parent or forking children so has not been an issue). One question regarding do(): > It's only if the code reference dies that C<do()> will check the connection. > If the handle is not connected to the database (because the database was > restarted, for example), I<then> C<do()> will create a new database handle and > execute the code reference again. > > I'm not quite sure how to handle the pings. I also don't like the idea of a ping every time a $dbh is needed. But, I wonder about re-issuing the query. If a do() throws an exception and then the connection is tested and fails the ping are you sure that the query didn't complete? My concern, of course, is running the query successfully twice. At one time I considered inspecting the error message and trying to determine if it came from the database so that I knew the query failed, and then reconnect and rerun the query, otherwise just die. Obviously, you can't reissue the query if in a transaction -- and I see you check for this. Checking the ping before returning $dbh isn't fool proof either. The connection could always die between the ping and then when $dbh is used. Is the history of the ping to catch connections that have been inactive for a long period and perhaps timed out? I've thought about only issuing the ping if the $dbh hasn't been fetched in some amount of time (say a few minutes) to effectively disable the pings when the site is busy (which should be most of the time). If you use it, you might also want "install your own cleanup handler to > issue a rollback on all open database handles at the end of every web > request," as Perrin says. Bricolage does that with its use of > connect_cached(), and that works great. It's safe to create a connection on > startup with DBIx::Connection though, as it is careful not to cache across > fork or thread boundaries. > But, if you use txn_do() for all transactions then is there any need for the cleanup handler rollback? I also see in your disconnect method that you manually issue a rollback, call disconnect and then undefine $dbh. Doesn't DBI do that automatically when $dbh is DESTROYed? -- Bill Moseley mose...@hank.org
