| 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: | Whole Thread | Raw Message | 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
| 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 |