On 19-Jun-06, at 7:15 PM, Oliver Jowett 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
>
> 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?
Good point, these would all have to be reset to their defaults as well.
>
> 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..
Since result sets only live as long as the statement, wouldn't they
point to the statement that is still open ?
>
> 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.
No question, and I would certainly not make this the default
behaviour. The user would have to turn on caching.
>
> 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.
How does the generic wrapper solve the problems above ? I would think
they all suffer from the same problems ?
>
> -O
>
