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

* Radosław Smogura (rsmogura@softperience.eu) wrote:
> > 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.

If it can't figure out a way to issue a command in between handing
around a connection to different clients then, yeah, I'd call it a bug
that needs to be fixed.  Maybe other systems don't need it, and it can
be a no-op there, but the capability certainly needs to be there.

> 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.

errr, I don't believe RESET ALL touches cache'd plans and whatnot (which
is actually a problem I've run into in the past, because changing the
search_path also doesn't invalidate plans, and neither does set role, so
you end up with cache'd plans that try to hit things you don't have
permissions to any more :( ).

	Thanks,

		Stephen