Re: statement caching patch from Laszlo Hornyak for review

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: statement caching patch from Laszlo Hornyak for review
Date: 2007-08-02 10:45:34
Message-ID: 46B1B5CE.1050409@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Dave Cramer wrote:
> Laszlo Hornyak has finished off the proof of concept patch that I
> submitted a few months ago.

Any reason you wrote your own scan-the-whole-pool LRU rather than using
something like LinkedHashMap?

I didn't dig into the code too closely but it looks like you are using
the statement object directly with no wrapper. Doesn't this run the risk
that you will resurrect a previously-closed statement? Normal statement
objects have a one-way lifecycle, once they are closed they cannot be
resurrected, if app clients have a reference to the real statement then
potentially they'll see different behaviour when the statement starts
getting reused. That smells dangerous; not because any sane application
will rely on it, but because it will be a source of very hard to find
bugs. (e.g. it's fairly common and harmless to close an already-closed
statement.. but that's suddenly disastrous if the statement has actually
been pooled & reused in the meantime)

Are all the abstract/interface/concrete-implementation classes strictly
necessary to get it operating under multiple JDBC versions? They are a
real pain when it comes to maintaining the code. For example I can't see
offhand why you need to do that with StatementPool.

-O

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Xavier Poinsard 2007-08-02 14:30:23 Re: LargeObject API
Previous Message Dave Cramer 2007-08-02 09:28:27 Re: statement caching patch from Laszlo Hornyak for review