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 <blblack@xxxxxxxxx> wrote:
>
> On 10/30/07, J. G. Konrad <konradjg@xxxxxxxxx> 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/dbix-class@xxxxxxxxxxxxxxxxx
>
|
