Re: statement caching proof of concept
От | Mark Lewis |
---|---|
Тема | Re: statement caching proof of concept |
Дата | |
Msg-id | 1150744887.19111.25.camel@archimedes обсуждение исходный текст |
Ответ на | statement caching proof of concept (Dave Cramer <pg@fastcrypt.com>) |
Список | pgsql-jdbc |
Hmmm. You know, an interesting alternative way to get the same kind of performance boost: cache just the handles to the server-side prepared statements, but not the Java PreparedStatement instances. I'm just suggesting the idea because it seems like it would be simpler to implement (just a pool and some ref-counting), and you wouldn't need to worry about any special concurrency issues, because you'd be dealing with distinct PreparedStatement object that just happen to refer to the same server-side statement. It seems like it would be less error-prone to only cache the expensive part, and leave the rest of the stateful stuff in PreparedStatement alone. But on the other hand, I'm not in a position to offer an alternative implementation, and working code trumps vaporware any day :) -- Mark Lewis On Mon, 2006-06-19 at 12:55 -0400, 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 > > 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 > > 2) Is it enough to cache prepared statements or should we cache > statements too? > > Note: this work is based completely on apache's dbcp statement > caching implementation and this will be noted in the final code. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
В списке pgsql-jdbc по дате отправления: