Using DBIx::Class 0.08007 and a simple script that will connect to a database, wait for greater than the timeout and execute a statement on a expired connection, everything works as described below. A new connection is made and the failing statement is retried. Setting DBIC_TRACE=1 shows the SQL twice even though only one ->single() is executed.
When using a Apache, mod_perl, Catalyst , DBIx setup, a new connection is created but the failing statement is not retried. It doesn't sound like this is the expected behavior. Am I missing something for this type of setup? On Oct 30, 2007 2:46 PM, 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]