From dev-return-9341-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Mon Oct 13 19:59:08 2008 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 74926 invoked from network); 13 Oct 2008 19:59:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Oct 2008 19:59:07 -0000 Received: (qmail 76528 invoked by uid 500); 13 Oct 2008 19:59:08 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 76503 invoked by uid 500); 13 Oct 2008 19:59:07 -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 76492 invoked by uid 99); 13 Oct 2008 19:59:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Oct 2008 12:59:07 -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: domain of techhusky@gmail.com designates 74.125.44.29 as permitted sender) Received: from [74.125.44.29] (HELO yx-out-2324.google.com) (74.125.44.29) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Oct 2008 19:58:02 +0000 Received: by yx-out-2324.google.com with SMTP id 8so441108yxb.63 for ; Mon, 13 Oct 2008 12:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=c10TTjpSuNJ4Q9wpgpdXTNSRJ5+JwYWXCxIUlQ2JHPk=; b=O8gkqD8KEfX4sWgib0Str+Qr22mY7Sy1Ne62re5m3GJnMXNXw/buus++XOJeXgnq+D ROaGtfmgCJfME8QNi6Kt3QLOx7Xx3nu2s4m7/o8CBTwia8SBiyGbvf3lGSiKlwAW7H8E +qhrOjc7Fo6Fhyo7uluL2IprgXUKvpMWvAwNQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=qGLI/2+ZIvA09QblIh0c60FdQhrS3jG0rabcGFsaRVsPl2WmLT4eQdKSQdeD0N3tZe d2SZKu59cBHID0hFjr9F+et8oWVSrEJswR9NcAji7CYr2ELz4XPGNoBz5svQgSIwXwi8 P0qTmdKpga3WkDc6yt1nUY+5KLx7QdhwmRd+M= Received: by 10.100.111.5 with SMTP id j5mr6355720anc.54.1223927918744; Mon, 13 Oct 2008 12:58:38 -0700 (PDT) Received: by 10.100.124.15 with HTTP; Mon, 13 Oct 2008 12:58:38 -0700 (PDT) Message-ID: Date: Mon, 13 Oct 2008 14:58:38 -0500 From: "Jeremy Bauer" To: dev@openjpa.apache.org Subject: Proposal to disable QuerySQLCache by default MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Checked: Checked by ClamAV on apache.org 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