Warren,
Interesting. This is good to know. I wasn't advocating abusing the
connection pool, but rather was wondering if the connection pool
suffered from the same issue. If we "release" a connection back to the
pool in a timely manner (well before server timeouts) there should not
be any issue with timeout. My understanding is if the pool has a
unexpired connection it will give it back to whomever requests it, but
once it expires on the pool it will reconnect to the server.
The rub comes from connections that have not expired in the pool after a
server restart - the next grab will fail (I just tested this using gdb).
I don't think there is anything a programmer can do about this except
retry. But then how do you purge (expire) all the connections in the
pool to get them to reset and do a fresh reconnect?
Just trying to gain an understanding on how we can make our application
more robust in this situation.
Dan
-----Original Message-----
From: Warren Young [mailto:mysqlpp@stripped]
Sent: Thursday, August 06, 2009 2:09 PM
To: plusplus@stripped
Subject: Re: Automatic Reconnect
On Aug 6, 2009, at 2:10 PM, Dan Cook (dancook) wrote:
> Would a connection pool help here?
Yeah, you could abuse it that way. :)
There's logic in there to let you tell it what the idle timeout is for
connections, so it will automatically close and restart them if it
detects that this has happened.
The stock code doesn't help with the cases where the remote DB server
is restarted, or your network link to it bounces. In the custom
ConnectionPool subclass -- which you had to derive anyway -- you could
do a ping-on-grab(), automatically closing the connection and creating
a fresh one if the ping fails.
This feels like abuse to me, though, because ConnecitonPool exists to
deal with cases where you would otherwise have unjustifiably many
connections open. You can run into the "lonely program dies over the
weekend" case with just one connection. With a single thread, that
may be all there ever is. So, you end up with this complicated pool
mechanism just to manage a single connection.
A pool for one. Call it ConnectionTub, if you must do it that way,
then.
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:
http://lists.mysql.com/plusplus?unsub=1
