Re: statement caching proof of concept redux

In June I posted this.

Since then we have some real results so I'd like to solicit ideas
from the group about implementing statement caching.

First and foremost it would be off by default and have to be
explicitly turned on. After that I'm wondering about parameters which
would affect resources. Would we want connection/database/driver
connection limits ? Do we do this by number of prepared statements ?
Overall memory consumption ?  Then there is aging of cached
statements; any ideas on how to age them? Will they need to be
invalidated after so much time ?


Any and all ideas are welcome.

I will post definitive results shortly. I've been promised them for a
few days now.

Dave

On 19-Jun-06, at 12:55 PM, 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.
>
> <statementcache.diff>
> <StatementPool.java>
> <CacheConnection.java>
> <CacheablePreparedStatement.java>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster