Re^3: Class::DBI, connect_cached and possible lost transactions?

I think you're over simplifyng a little. TCP/IP is involved here, so even the ping will wait for some period of time. Also, the database library (provided by Oracle in your example) may attempt to handle momentary outages. I know the MySQL one does. If the outage was just the right amount of time though, it could happen, and the same for the failover scenario.

It's definitely safer to not try to reconnect during a web request. If you'd rather not touch Ima::DBI, you can override db_Main in your Class::DBI base class.

Comment on Re^3: Class::DBI, connect_cached and possible lost transactions?

Replies are listed 'Best First'.
Re^4: Class::DBI, connect_cached and possible lost transactions? by Anonymous Monk on May 05, 2006 at 14:52 UTC
Perrin: Thank you for your ensight. Please allow me ask another question. From reading your posts on various forums, it appears that your environment is similar to the environment I work in. Are you concerned about this possibilty of lost transactions? Do you override Ima::DBI's _mk_dbi_closure, or Class::DBI's db_Main in the transaction based applications you develop and support to ensure that connect is called just once per request, for mod_perl and/or plain mod_cgi? Thank you, Perrin.	[reply]
Re^5: Class::DBI, connect_cached and possible lost transactions? by perrin (Chancellor) on May 05, 2006 at 21:30 UTC
I haven't dealt with it because I consider it very unlikely. Most failover systems are not fast enough to be an issue (i.e. the reconnect attempt will fail because the new db is not up yet), and the MySQL client libraries handle momentary outages pretty well. It would be a good idea, but it's the least of my worries really.	[reply]