[odb-users] MySQL timeout: ODB not reconnecting?

[Boris Kolpackov]

Hi Dieter,

Dieter Van de Walle <dieter.vandewalle at newtec.eu> writes:

> We've been using ODB for persistency for a while now, and it is working
> very smoothly. There's some improvement possible, but very impressed.

Thanks, I am glad you are enjoying it.


> I have just encountered an annoying problem with the connection management
> of ODB though. When a DB connection is inactive, MySQL will timeout the 
> connection after 8 hours. This causes ODB to lose the connection and fail
> any further DB actions with the error: "ODB error: 2006 (HY000): MySQL
> server has gone away" . 
> 
> Apparently the 'connection_pool_factory' does not reconnect when 
> connections are gone... ??
> 
> I was able to fix this by using the 'new_connection_factory' instead of
> the default 'connection_pool_factory'. The 'connection_pool_factory'
> should check connection status though and reconnect if necessary it
> seems?

Yes, we were actually thinking about the same functionality. We won't be
able to use MySQL reconnect feature because such transparent reconnects
release prepared statements and ODB uses them heavily. But the pool
factory can check the connection with mysql_ping before giving it out to
the caller. If the connection has been lost, it can close it and create
a new one. This will work transparently to the ODB users.

There is, however, another related situation which we won't be able to
handle transparently. Imagine that the connection is lost (e.g., due to
an intermittent network failure) during a transaction. In this case the
transaction will have to be rolled back (even MySQL auto-reconnect cannot
transparently handle this case). You, as a user of ODB, will need to
detect this situation (by catching an exception) and retry the transaction,
similar to how it is done now with deadlocks.

So the current plan is to introduce a special base exception, odb::recoverable,
from which all potentially recoverable exceptions, such as odb::deadlock,
odb::connection_lost, and odb::timeout, will derive. You will then be able
to catch this exception and retry the transaction.

Let me know if this sounds good to you and we will add this functionality.

Boris