"Peter V. Cooper" <pvcooper@gte.net> writes:
> I make the assertion that a servlet which has a connection open
> to the database at all times (a servlet/tomcat connection object)
> and is physically located on the same LAN as the database could
> easily have a Internet user connected remotely step away from
> his/her desk for an hour or more and then return to run a
> JDBC statement. This would cause the JDBC driver to attempt
> to use the connection object. In using this connection object
> I am told, and will verify personally, that the information on the
> closed connection may take 30 seconds to inform the JDBC
> client running in the middle tier that the connection is closed
> and that code needs to be run to reconnect this connection.
If true (which I doubt), the problem is *entirely* on the client side.
Neither the backend nor the TCP transport layer would have the
slightest difficulty with this scenario. The KEEPALIVE timeout I
mentioned would only come into play given an hour-long connectivity
failure of your LAN, or a system-level crash of your client machine,
neither of which are likely to result from a user taking a lunch break.
However, I'm not very familiar with Java and so I cannot dismiss the
possibility that some layer inside the JVM might take it upon itself
to close an open TCP connection after a period of inactivity.
If you are able to reproduce a problem of this sort then you need to be
looking inside the Java code. The backend is not causing it.
The pgsql-jdbc list might be a better place to ask if anyone knows of
such problems in a JDBC context. Not sure how many JDBC people read
pgsql-bugs.
regards, tom lane
