Re: New to Postgresql - Backend timeout /JDBC
От | Tom Lane |
---|---|
Тема | Re: New to Postgresql - Backend timeout /JDBC |
Дата | |
Msg-id | 3856.1012499876@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: New to Postgresql - Backend timeout /JDBC ("Peter V. Cooper" <pvcooper@gte.net>) |
Ответы |
Re: New to Postgresql - Backend timeout /JDBC
|
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: