On Mon, 2006-02-13 at 13:08 -0500, RJ Herrick wrote: > What I've gathered is that since persistent connections are per child > apache process, any such problem that might arise would be due to the > same child not cleaning its dbhandle attributes up between calls.
Yes. > Normally this would be done at the end of the script by DBI No, normally it just wouldn't matter because no one would use the handle again. > Apache::DBI does do this cleanup before > returning the dbhandle on each call (via a rollback unless AutoCommit is > on, and possibly a separate cleanup for the "other parameters" regardless). It only does a rollback. It does no other cleanup. Any other parameters that have to be reset must be handled by you. > So it seems the short answer is: use Apache::DBI if using DBI with > mod_perl? You don't have to, but it does provide some things that you need, like rollbacks if you use transactions, automatic reconnects if you lose your connection, and prevention of caching handles during startup. > I'm not familiar with Apache::DBI, I thought that the > connection would persist under mod_perl simply because the handle isn't > destroyed until the child dies. If you store the handle in a global, this is true. It may time out though, if your server is not busy. > Perrin- I would test this myself... except that, crazy as it sounds, I'm > not currently using mod_perl. It doesn't matter -- you can test this from any old command-line script. Just open a connection, do an insert that works, do one that doesn't work (duplicate key or something), and check the isertid. - Perrin
