Dave Cramer wrote:
> I just noticed this:
>
> Now that JDBC 4 has a notion of pooling built right into the statement
> interface it is clear (to me at least) that the implementation belongs
> in the driver.
In chapter 11.6, "Reuse of Statements by Pooled Connection", the spec says:
> In FIGURE 11-2, the connection pool and statement pool are implemented by the
> application server. However, this functionality could also be implemented by the
> driver or underlying data source. This discussion of statement pooling is meant to
> allow for any of these implementations.
The new methods added in JDBC4, setPoolable and isPoolable are for use
by applications to hint the connection pool implementation which
statements it should try to pool. Statements are poolable by default, so
it's really for telling the pool not to bother pooling one off queries.
I still don't think it's wise for us to bundle a statement cache in the
driver. If we had a server-side statement cache, or if there was some
other PostgreSQL specific trick we could take advantage of, it would
make sense to provide an interface for it. But there isn't.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com