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