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
Isn't there a bunch of statement state (things like fetch size, max
rows, etc) that have defined defaults and this cache implementation will
not provide?
The "wrapper" implementation approach suffers from the usual difficulty
that the "back links" such as ResultSet.getStatement() point to the
wrong object. It's actually quite a bit of work to get this right..
The cached statements are vulnerable to buggy apps that mutate the
statement after close, since there's no interception of those methods to
check whether the wrapper statement has been closed.
What exactly is the performance bottleneck you're trying to avoid by
having the statement pool? If it's the parse/plan cost, I think Mark's
suggestion of putting the cache at the protocol level may be simpler. If
it's overall statement cost, you might be better off with a generic
wrapper that is not postgresql-specific at all.
-O
