Re: statement caching proof of concept

On 19-Jun-06, at 2:57 PM, till toenges wrote:

> Dave Cramer wrote:
>> This is just proof of concept. More work has to be done to make it
>> build properly and work properly under different jdk's
>
> Interesting. How is it intended to be used? Automatically for every
> prepared statement? How does this compare to other JDBC
> implementations?
Essentially yes, however this is all good feedback. The way it's
implemented we could use it or not on a per connection basis.
>
> And, why would this be a part of the Postgres driver? It seems more
> like
> an add-on to JDBC drivers in general. I do use a pool for prepared
> statements myself, actually quite like the one you wrote. But it is
> part
> of my general database related code library.

Other drivers use statement caching namely Oracle.
>
> Don't get me wrong, if there is a clean way to boost the
> performance of
> the driver without allocating too many resources, i'd like to see
> it in
> the driver. But if it is complicated to use, or tries do to "clever"
> things behind my back, i'm not so sure. Maybe activate it via a
> parameter like preparedThreshold?

All good feedback
>
>> Couple of questions.
>>
>> 1) What to do if there are multiple concurrent requests per
>> connection for the same statement?
>> 1) we could just allow it
>> 2) we could return a non-cacheable preparedstatement
>> 3) throw an exception
>
> Should do whatever a normal prepared statement would do in this
> situation, imho. That is, if i have code that uses normal prepared
> statements, and is updated to use these cached statements, it
> should not
> fail in any new ways. Or either the different behaviour it must be
> very
> well documented.

I'd agree the driver should not fail.
>
>> 2) Is it enough to cache prepared statements or should we cache
>> statements too?
>
> Actually, if i don't use a prepared statement, i want just this: do it
> once, then forget about it. Though it could be nice to boost stupid
> code
> that doesn't know about prepared statements; which is not really a
> problem of the driver.
>
>> Note: this work is based completely on apache's dbcp statement
>> caching implementation and this will be noted in the final code.
>
> What does that mean?
Nothing much, I am just giving credit where credit is due. I borrowed
most of the concepts from them.

Their license like ours allows this.

Dave
>
>
> Till
>