On Tuesday 16 January 2007 17:35, Oleg Broytmann wrote:
> On Tue, Jan 16, 2007 at 06:28:53PM +0300, Oleg Broytmann wrote:
> > > Further, Dan had also some concerns about transactions. He wrote
> > > that if the reconnectiong would happen at MySQLdb level, it could
> > > be handled gracefully, but that things will get messed up which the
> > > patch to SQLObject, if transactions are involved.
> > Yes, I remember. This means we have to point everyone to the
> > MySQLdb patch instead of implementing anything in SQLObject.
> Well, I see. There are two different problems - connection timeout
> and server restart. They have to be handled differently. Connection
> timeout has to be handled in the DB API driver. Server restart - in the
IMO, I see no reason why a server restart cannot be handled by the same
reconnect feature of the underlying mysql library. From the sqlobject
point of view the situation is the same, no matter if the connection did
timeout or the server was restarted. Once it timeouts a connection ceases
to exist in the server much like when the server is restarted and looses
all the connections.
If the reconnect patch is applied to mysqldb, sqlobject needs no changes
and shouldn't care about handling a restarted server (not that it can
tell if the server died, was restarted or closed the connection because
it was idle, anyway).
In the end, probably the situation can be handled in sqlobject completely,
if the transaction code takes care not to reconnect, but to raise an
exception. Thus if no transactions are used, then the code can create a
new connection everytime it detects a dead one, but if the connection is
a transaction object in the middle of a transaction then it should just
raise an error.
However I fail to see the point to reimplement all this logic in sqlobject
when it is already implemented by the mysql library. All that is needed
is to make the reconnect option available to the python level and the
solution is already out there, except that somebody insist on ignoring it
for no good reason.