I echo Tim's comments. We looked into implementing auto reconnect for
our applications (e.g. in the case of the DB going down) and unless you
have a *very* simple scenario it was just too much work to save and
restore state.
For example, you could lose the connection between a ->prepare and an
->execute. On reconnecting you would need to know to go back and
prepare the statement again.
What if you were in the middle of a transaction? On reconnect you would
need to know when the last commit happened and redo any work since then.
Very messy if not impossible to handle in a generic way.
Steve
On Wed, 2008-11-12 at 15:41 +0000, Tim Bunce wrote:
> On Tue, Nov 11, 2008 at 11:27:59AM -0500, Patrick Galbraith wrote:
> > John,
> >
> > Hi! DBD::mysql uses mysql_auto_reconnect to connect back to MySQL if the
> > connection drops
> >
> > $dbh= DBI->connect('DBI:mysql:test:mysql_auto_reconnect=1', $foo, $fee)...;
> >
> > or of course
> >
> > $dbh->{mysql_auto_reconnect};
> >
> > In the perl side of the driver:
> >
> > if ($this && ($ENV{MOD_PERL} || $ENV{GATEWAY_INTERFACE})) {
> > $this->{mysql_auto_reconnect} = 1;
> > }
> >
> > I had this off once with a release I did, and a lot of people were very
> > unhappy ;)
>
> I hope they all appreciate the risks they're taking if they use locks
> or any other server state that would be silently lost by an auto reconnect.
>
> > So, whatever might give the functionality to reconnect automatically
> > I suppose it'd be the same as doing
> >
> > unless ($dbh->ping) {
> > $dbh= .... connect ...
> > }
>
> The DBI spells that DBI->connect_cached(...)
>
> Tim.
******************************************************************
This email is intended solely for the use of the addressee and may
contain information that is confidential, proprietary, or both.
If you receive this email in error please immediately notify the
sender and delete the email.
******************************************************************
