The attached is the second version of setKeepAlive patch, which enables
that user can turn the configuration flag on/off. The default is off.
2008/2/10, Oliver Jowett <oliver@opencloud.com>:
> I agree that aggressive keepalives are not particularly useful in that case.
I agree the above too, and I don't think TCP keepalive is a perfect
solution. As Gregory already said, to provide a detailed
application-specific monitoring, some kind of application level test
(maybe using setQueryTimeout()) is still needed.
But nonetheless I think some of the cases are solved by this simple
keepalive.
For instance, resource collection without server rebooting on an
application server side, which is occupied by lost connections:
1. There are master-slave database servers connecting to a shared disk,
and application servers connect the master server first.
2. If the master database server gets down and fails over to the slave
server by a high-availability clustering suite, then connections from
the application servers to the master server are remained and not to be
collected, because JDBC driver doesn't send any exceptions in this case,
so application can't take measures to solve it.
3. If hundreds / thousands of connections are remained, a large quantity
of resources used by the lost connections die in vain and should be
removed without application server rebooting sooner or later.
I do hope all the dead server detection is implemented. I'd like to
avoid JDBC driver doesn't say anything in this case now. It seems to
me implementing setQueryTimeout() is so easy as doing setKeepAlive().
I think this patch just provides the least-level assuarance.
Best regards,
