Re: statement caching proof of concept
От | Dave Cramer |
---|---|
Тема | Re: statement caching proof of concept |
Дата | |
Msg-id | 5A43640B-3C41-4D07-AA9E-588AD8AAD343@fastcrypt.com обсуждение исходный текст |
Ответ на | Re: statement caching proof of concept (till toenges <tt@kyon.de>) |
Ответы |
Re: statement caching proof of concept
|
Список | pgsql-jdbc |
On 19-Jun-06, at 2:57 PM, till toenges 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 > > Interesting. How is it intended to be used? Automatically for every > prepared statement? How does this compare to other JDBC > implementations? Essentially yes, however this is all good feedback. The way it's implemented we could use it or not on a per connection basis. > > And, why would this be a part of the Postgres driver? It seems more > like > an add-on to JDBC drivers in general. I do use a pool for prepared > statements myself, actually quite like the one you wrote. But it is > part > of my general database related code library. Other drivers use statement caching namely Oracle. > > Don't get me wrong, if there is a clean way to boost the > performance of > the driver without allocating too many resources, i'd like to see > it in > the driver. But if it is complicated to use, or tries do to "clever" > things behind my back, i'm not so sure. Maybe activate it via a > parameter like preparedThreshold? All good feedback > >> Couple of questions. >> >> 1) What to do if there are multiple concurrent requests per >> connection for the same statement? >> 1) we could just allow it >> 2) we could return a non-cacheable preparedstatement >> 3) throw an exception > > Should do whatever a normal prepared statement would do in this > situation, imho. That is, if i have code that uses normal prepared > statements, and is updated to use these cached statements, it > should not > fail in any new ways. Or either the different behaviour it must be > very > well documented. I'd agree the driver should not fail. > >> 2) Is it enough to cache prepared statements or should we cache >> statements too? > > Actually, if i don't use a prepared statement, i want just this: do it > once, then forget about it. Though it could be nice to boost stupid > code > that doesn't know about prepared statements; which is not really a > problem of the driver. > >> Note: this work is based completely on apache's dbcp statement >> caching implementation and this will be noted in the final code. > > What does that mean? Nothing much, I am just giving credit where credit is due. I borrowed most of the concepts from them. Their license like ours allows this. Dave > > > Till >
В списке pgsql-jdbc по дате отправления: