On Jun 22, 2013, at 4:09 AM, springrate rate.spring@hotmail.com wrote:
hi, i read source, maybe this is true? after the pool started, the conn in pool can be always healthy. in real word, conn can be disconnected. in this situation, client get a conn from pool, when using the conn, executing or querying can get a exception when conn is disconnected. how to process the exception? conn need a reconnection operator or free conn and new a connection.
On exception you might use Connection_ping to implicit test if the connection is alive and if not, get a new connection from the pool and retry. In practice I'm not sure how useful this is and personally I think you are better off to just fail with an error. With TCP Database connections a network problem might occur at anytime and it's better not to over-think this.
may be Connection need a status and reaper thread can check conn's status and try reconnect and keep enough connection when db service function recover.
The pool always makes sure that a connection is alive before it is handed out. In addition, the reaper thread continuously test that available connections are connected and close those that are not. Finally, for MySQL, auto-reconnect is enabled and Postgres use TCP keep-alive. Together I believe these strategies, in practice, is good enough to ensure that connections in the pool are reasonable healthy.
If anyone has experiences that libzdb is not able to maintain a healthy pool of connections I'll be most interested to hear about it, of course.