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

Dieter Van de Walle dieter.vandewalle at newtec.eu
Fri Feb 18 10:02:14 EST 2011

Hello Boris, 

In the perfect case, ODB should handle this transparantly. 
So the behaviour I would like most is the following: 
In case the DB connection is lost, ODB automatically and transparantly tries to reconnect. 

The following parameters should be configurable: 
- Try to auto-reconnect / immediatly throw exception 
- Connection timeout 
- Number of times to try to connect before exception is thrown 

Most errors are caused by MySQL terminating a connection because of a timeout. 
In that case, a quick transparant reconnect will work very well. 

If the network goes down, I don't mind if ODB blocks for a while while trying to 
reconnect before throwing an exception. 

Thanks for the work on this great software! 


----- Original Message -----
From: "Boris Kolpackov" <boris at codesynthesis.com> 
To: "Dieter Van de Walle" <dieter.vandewalle at newtec.eu> 
Cc: odb-users at codesynthesis.com 
Sent: Monday, 14 February, 2011 1:16:02 PM 
Subject: Re: [odb-users] MySQL timeout: ODB not reconnecting? 

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. 


Newtec’s MENOS system awarded IBC Innovation Award for Content Delivery & the IBC Judges’ Award  Newtec’s FlexACM awarded 2009 Teleport Technology of the Year by WTA  *** e-mail confidentiality footer *** This message and any attachments thereto are confidential. They may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. E-mail transmission cannot be guaranteed to be secure or error free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore is in no way liable for any errors or omissions in the content of this message, which may arise as a result of e-mail transmission. If verification is required, please request a hard copy.

More information about the odb-users mailing list