I agree completely that keepalive is the more correct solution but
that the ability to set the timeout to something reasonable is a plus
for sotimeout.
That said, I'll take a shot at listing a few pros and cons for
allowing access to either.
Cons:
1. It could be confusing to a developer when the connection if a
connection is dropped (especially when doing a long running query).
2. I'm assuming (and please correct me if not) that postgresql will
continue to run a long query until trying to access the socket again.
If true, code could be written where it leads to a user submitting the
same long running queries to the database thinking there is just a
transient problem.
Pros:
1. Either or both are useful in unusual/unreliable networking
situations.
2. With correct settings and infrastructure, allowing the socket close
itself, can keep a connection pool from filling and threads from
hanging.
3. Setting sotimeout is available in some other major drivers (Oracle
odbc5, IBM db2jcc and jdts).
Art Gramlich
Chief Application Architect
HealthTrio, LLC
art.gramlich@healthtrio.com
On Apr 10, 2008, at 5:51 PM, Kris Jurka wrote:
>
>
> On Thu, 10 Apr 2008, Art Gramlich wrote:
>
>> They do. We usually have different connection pools for normal
>> (short running) and long queries. Since almost all are short
>> running, this has worked well for us. I actually haven't tried
>> setting keepalive in this situation. so I can't say much, but the
>> vpn solutions we have used have at times gotten into some pretty
>> wierd states and sotimeouts could stop our pools from going crazy.
>>
>
> I can see how keepalives are generally useful while sotimeouts are
> only useful in the specific situation where you can set a global
> limit on your query times. On the other hand the sotimeout is
> configurable while the keepalive timeout isn't configurable (at
> least in Java). I'm not particularly excited about either option,
> but I don't need them either.
> I don't see a danger with exposing them as options as long as the
> pros and cons are clearly explained.
>
> Kris Jurka
