> Hi!!
> Does anyone knows if it is possible to check if a database connexion is
> good (the connexion may be lost because of a timeout, or there is a
> network problem, ... ) before using it?
Depends on your DB API. Usually what's done in Java is to try to do
whatever it is you want done, and catch exceptions if it screws up (and
perhaps releasing resources or rolling back transactions in
finally-clauses).
- Oliver
eldie - 10 Jun 2006 11:09 GMT
Hi, thank you for replying ;-)
We have implemented our own pool of connexions and there is already a
lot of code that uses this pool (and everywhere when the connexion is
used the code assumes that the connexion provided by the pool is a
"good" connexion). That's why I want to find a way to test the state
of the connexion inside the pool (this would be much more easier than
changing the code everywhere).
shakah - 11 Jun 2006 13:21 GMT
> Hi, thank you for replying ;-)
> We have implemented our own pool of connexions and there is already a
[quoted text clipped - 3 lines]
> of the connexion inside the pool (this would be much more easier than
> changing the code everywhere).
I have a similar home-grown DB connection pool, and I test the
connection by performing a "SELECT CURRENT_TIMESTAMP" command before
returning it as a valid connection (if it fails I throw out the
connection and try to find another (or establish another one)).
eldie - 13 Jun 2006 19:42 GMT
Hi shakah,
We have done exactly the same thing (I think we have no choice), but
our question is the performance... we are doing to duplicate the number
of requests to the data base....
shakah - 14 Jun 2006 13:08 GMT
> Hi shakah,
> We have done exactly the same thing (I think we have no choice), but
> our question is the performance... we are doing to duplicate the number
> of requests to the data base....
You might be duplicating the number of requests, but the extra request
you're making is a lightweight as it can be -- the socket is already
open, and retrieving the CURRENT_TIMESTAMP (or a literal 'x' of 1, for
that matter) shouldn't load the database server in any meaningful way.