Skip site navigation (1) Skip section navigation (2)

Re: [JDBC] Support for JDBC setQueryTimeout, et al.

From: Radosław Smogura <rsmogura(at)softperience(dot)eu>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: David Fetter <david(at)fetter(dot)org>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL JDBC List <pgsql-jdbc(at)postgresql(dot)org>, <robertmhaas(at)gmail(dot)com>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Date: 2010-10-15 09:11:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-jdbc
On Fri, 15 Oct 2010 10:37:05 +0200, Magnus Hagander <magnus(at)hagander(dot)net>
>> But... connection pooler will not send RESET ALL in some situations,
>> because JDBC driver can have no notify about switching client. In EE
>> platforms (e. g. Glassfish), server sometimes creates it's own pool and
>> in
>> certain configuration, when you close Connection, server will never
>> close to PooledConection, nor physical connection. This due to fact,
>> GF and others adds functionality for statements pooling (if server will
>> call close on pooled conn, then reusing cached statement will cause
>> error -
>> in fact this problem occurs with Hibernate, C3po, XA, and GFv3).
> To me, that sounds like a bug in the connection pooler. It is only
> safe under quite limited circumstances.

It's hard to say this is bug. The GF connection pooler is "general pooler"
for all drivers, so it can't know anything about reseting, and if I have
right JDBC4 doesn't support such notifications. It can't close logical
connections, as if would close, cached statements will be invalideted too.

But benefits of pooling statements are much more greater then RESET ALL,
because you can take advance of precompiling prepared statements,
increasing performance; it is comparable to using connection pool instead
of starting physical connections.

In ~2008, Sun published result of (spectest?) Glassfih v2 and PostgreSQL
with special patches allowing statement caching (on JDBC driver side) - it
was the fastest combination, biting all "professional" and highly paid

Probably same wrapping can do JBoss, WAS, and others.

>> in fact this problem occurs with Hibernate, C3po, XA, and GFv3).
Hibernate, with C3P0 hacks and uses some private code, unwraps objects,
etc... :(, so when private implementation changes we have BUM.

> -- 
>  Magnus Hagander
>  Me:
>  Work:

Radosław Smogura

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-10-15 09:20:51
Subject: Re: [HACKERS] Docs for archive_cleanup_command are poor
Previous:From: Dimitri FontaineDate: 2010-10-15 08:57:41
Subject: Re: Extensions, this time with a patch

pgsql-jdbc by date

Next:From: Stephen FrostDate: 2010-10-15 14:21:26
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.
Previous:From: Magnus HaganderDate: 2010-10-15 08:37:05
Subject: Re: [JDBC] Support for JDBC setQueryTimeout, et al.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group