Re: statement caching proof of concept redux

Statement caching results.

I have some numbers although I can only share relative numbers.

Statement caching provides a 40% increase in throughput. So I think
this is worth doing.

Dave
On 1-Mar-07, at 8:59 PM, Dave Cramer wrote:

> 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
>
>