On Fri, 15 Oct 2010 10:37:05 +0200, Magnus Hagander <magnus@hagander.net>
wrote:
>> 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
pass
>> close to PooledConection, nor physical connection. This due to fact,
that
>> 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
software.
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: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/
--
----------
Radosław Smogura
http://www.softperience.eu