Hmmm. You know, an interesting alternative way to get the same kind of
performance boost: cache just the handles to the server-side prepared
statements, but not the Java PreparedStatement instances.
I'm just suggesting the idea because it seems like it would be simpler
to implement (just a pool and some ref-counting), and you wouldn't need
to worry about any special concurrency issues, because you'd be dealing
with distinct PreparedStatement object that just happen to refer to the
same server-side statement.
It seems like it would be less error-prone to only cache the expensive
part, and leave the rest of the stateful stuff in PreparedStatement
alone.
But on the other hand, I'm not in a position to offer an alternative
implementation, and working code trumps vaporware any day :)
-- Mark Lewis
On Mon, 2006-06-19 at 12:55 -0400, 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
>
> 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
>
> 2) Is it enough to cache prepared statements or should we cache
> statements too?
>
> Note: this work is based completely on apache's dbcp statement
> caching implementation and this will be noted in the final code.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster