I'm not sure if this is worth anything but one of our dev machines that had been working ( no lost connections ) with version 0.07002 of DBIx::Class didn't work with 0.08007. Within the first few requests after upgrading to 0.08007, lost connection.
On 10/30/07, Brandon Black <[EMAIL PROTECTED]> wrote: > > On 10/30/07, J. G. Konrad <[EMAIL PROTECTED]> wrote: > > I was wondering if anyone had experience with this type of error, "DBI > > Exception: DBD::mysql::st execute failed: Lost connection to MySQL > server > > during query" while using DBIx::Class ? > > > > our MySQL server was getting swamped with too many connections so I > changed > > the wait_timeout to 30 seconds rather then the default of 28800 > seconds. In > > previous post that I read there is reconnecting behavior and this should > > work. That is, if the connection is gone ( timed out ) , DBIx::Class > will > > reconnect. Am I hitting some kind of race condition with the > reconnection > > behavior? > > > > I am using version 0.08003 DBIx::Class. > > > > > > any thoughts / comments are appreciated. > > > > The reconnect behavior of DBIx::Class was intended for when you get > disconnected in-between statements. I'm not familiar with this issue > of MySQL disconnecting a query that's in-progress. I would hope that > means the query has no side-effects (in the case of a txn, or even an > isolated update/insert/delete via AutoCommit). > > That being said, the way the reconnect code currently operates is that > after a DBI exception it checks to see whether the connection is still > alive. If it isn't, it assumes that's the cause of the exception and > then reconnects and retries the statement or transaction. However, it > will only do this exactly once per statement/txn attempt on your part. > If it's happening twice in a row (quite possible in the scenario > you're describing), it won't save you on the second failure in a row > of the same statement/txn. > > The logic behind the "only reconnect+retry once per statement/txn" > idea is that we want to protect from things like disconnects due to > idle sessions or rebooted servers, but we don't want to retry > indefinitely if we keep getting disconnected (because that probably > means we're triggering a bug and killing the connect (or server) with > our statement, or something even worse, that needs to be addressed > manually). > > You definitely should upgrade DBIx::Class though, there were related > bugfixes (in general - perhaps not specific enough to your case) since > 0.08003 IIRC. > > -- Brandon > > _______________________________________________ > List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class > IRC: irc.perl.org#dbix-class > SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ > Searchable Archive: > http://www.grokbase.com/group/[EMAIL PROTECTED] >
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
