Typically, a DB(I) connection will remain open until you close (disconnect) it. In other words, not closing it before exiting the application should be sufficient to achieve persistence... (In case you're using a lexical variable to hold the db handle, make sure it doesn't unintentionally go out of scope, or else the object's DESTROY method will automatically disconnect.)
Update: In this particular case, where there will likely be
only one set of connect() parameters, I don't really see any
significant advantage of using connect_cached() over using a
plain connect() plus simply keeping around and 'reusing' the
obtained $dbh yourself... —
Except maybe for the implicit ping being done behind the scenes,
which might guard you (to some degree) against the rare case that the
connection has disappeared in the meantime (due to network problems, DB
restart or whatever). This might make more sense for a web app where the
server part keeps running for months, but for the typical usage scenario
of a standalone wxPerl GUI it seems less vital...
In other words, if anyone feels like pointing out the specific
advantages of using connect_cached(), please go ahead!
| [reply]
[d/l]
[select] |
This is something Apache::DBI does. If you want to do it yourself, you could look at that source for ideas. Basically it holds the database handle for you. When you ask for it, it checks (with the $dbh->ping method) to see that it's still alive and reconnects it if necessary before giving it back to you.
| [reply]
[d/l] |
The DBI->connect_cached method does all that too. Apache::DBI adds some web-specific stuff, like disabling disconnect() for porting of old CGI scripts, avoiding caching during server startup, and rolling back any unfinished transactions that could be left at the end of a request if your code died.
| [reply] |
Hi,
Regardless of the strategy you gonna use, connect_cached or having your own recovery, encapsulate it in your own module instead of directly calling DBI module.
Regards,
fmerges at irc.freenode.net
| [reply] |
