From dev-return-9347-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Tue Oct 14 16:58:16 2008 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 99690 invoked from network); 14 Oct 2008 16:58:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Oct 2008 16:58:16 -0000 Received: (qmail 6697 invoked by uid 500); 14 Oct 2008 16:58:16 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 6680 invoked by uid 500); 14 Oct 2008 16:58:16 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 6669 invoked by uid 99); 14 Oct 2008 16:58:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Oct 2008 09:58:16 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [216.252.110.64] (HELO web55903.mail.re3.yahoo.com) (216.252.110.64) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 14 Oct 2008 16:57:10 +0000 Received: (qmail 45758 invoked by uid 60001); 14 Oct 2008 16:57:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=O7CQ0plyOHnOqrwB4iz1EB2pJ0FMs5AmdunYppl9/1GUX5ndeVqO5L5Lk1n0lwmVojoV9rD79vv15T5NQyZeNd9o7AIbnMCEE1i55xyLSNt5PMr15GSbYGbsLAKggyIoU5yeIaF+MDeRxtXTSw8EPVhZfQgWAnPR2eYrRnflIgo=; X-YMail-OSG: oItK4dwVM1nU_15cVodlhJJv5zZZQgkQRAu5PBr1couo1pPJ5Y_wRzcWP93a2okWGt3ReZ7.Q55zM.97d_pakJrTOqgEnEeoqJTGqcwiDF1xOycfelOPaDVDNE33atdICsg0p2xl.oJpnYYqqSCtvE4XmLuU4w4THid8_xur9ZpQr8q.D_.Nt11FTYAdLirbjPtT6TguFR8oXzM- Received: from [129.42.184.35] by web55903.mail.re3.yahoo.com via HTTP; Tue, 14 Oct 2008 09:57:46 PDT X-Mailer: YahooMailWebService/0.7.218.2 Date: Tue, 14 Oct 2008 09:57:46 -0700 (PDT) From: Fay Wang Reply-To: fyw300@yahoo.com Subject: Re: Proposal to disable QuerySQLCache by default To: dev@openjpa.apache.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <798368.45319.qm@web55903.mail.re3.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org 1+ This QuerySQLCache is to cache SelectImpl and SQLBuffer for the findBy operation without making too much architectural change in the current findBy code path. Although it works fine in the "normal" situations with significant performance gain, it is undoubtedly not tested in all scenarios. A better approach is to have a cleaner architecture sitting on top of the current framework to cover the SelectImpl/SQLBuffer cache for both findBy operation and dynamic JPQL query. --- On Mon, 10/13/08, Jeremy Bauer wrote: > From: Jeremy Bauer > Subject: Proposal to disable QuerySQLCache by default > To: dev@openjpa.apache.org > Date: Monday, October 13, 2008, 12:58 PM > Dev's, > > We've had a few regression-type issues (OPENJPA-660 > & OPENJPA-731) > since the addition of QuerySQLCache in 1.2.0. While this > cache has > shown to provide significant performance improvements for > certain > scenarios, I think we should consider disabling the cache > by default. > The main reason is the potential for future regression > issues. > Another reason is that we didn't follow the pattern set > by existing > caches. With the exception of the query compilation cache > (which is > relatively static after queries are initialized), the other > caches are > disabled by default. While the cache is supposed to be > transparent, > it could (and has shown to) affect the behavior of an > application that > has been working for quite some time on a prior release. > > Arguably, QuerySQLCache may just need more rigorous > testing. While > additional testing may help, testing every scenario is > difficult and > if we miss one, regression issues due to performance > enhancements are > pretty hard to swallow. I think a better approach is to > allow users > to enable the cache if they choose to do so. > > What do y'all think? If we get a consensus, I'll > open an issue to > make the necessary changes to disable the cache. > > -Jeremy