Re: statement caching patch from Laszlo Hornyak for review
| От | Oliver Jowett |
|---|---|
| Тема | Re: statement caching patch from Laszlo Hornyak for review |
| Дата | |
| Msg-id | 46B1B5CE.1050409@opencloud.com обсуждение исходный текст |
| Ответ на | statement caching patch from Laszlo Hornyak for review (Dave Cramer <pg@fastcrypt.com>) |
| Ответы |
Re: statement caching patch from Laszlo Hornyak for review
|
| Список | 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
В списке pgsql-jdbc по дате отправления: