On 30-Aug-07, at 4:14 AM, Heikki Linnakangas wrote:
> 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.
Well, that's yet to be discovered. We are in the process of making a
wrapper driver which we will test for speed.
If the same throughput can't be achieved due to the overhead of
proxying the calls then there is a good argument for providing
statement caching inside the driver.
Dave
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com