Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 17682 invoked from network); 27 May 2008 22:00:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 May 2008 22:00:51 -0000 Received: (qmail 43260 invoked by uid 500); 27 May 2008 22:00:53 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 43212 invoked by uid 500); 27 May 2008 22:00:53 -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 43201 invoked by uid 99); 27 May 2008 22:00:53 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 May 2008 15:00:53 -0700 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 May 2008 21:59:59 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1K17DQ-0000Np-LX for dev@openjpa.apache.org; Tue, 27 May 2008 15:00:20 -0700 Message-ID: <17501042.post@talk.nabble.com> Date: Tue, 27 May 2008 15:00:20 -0700 (PDT) From: Pinaki Poddar To: dev@openjpa.apache.org Subject: Re: datacache In-Reply-To: <63567AAF-241E-4DDC-9653-F79EF4CBD997@SUN.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: ppoddar@apache.org References: <864cafc0805191241o2a6d1df2jb3086aa6e40f90b0@mail.gmail.com> <63567AAF-241E-4DDC-9653-F79EF4CBD997@SUN.com> X-Virus-Checked: Checked by ClamAV on apache.org After some more analysis of refresh() issue... 1. it is observed that a refresh of a single, clean instance never hits the database -- irrespective of whether Data Cache is active or not. That does not appear spec compliant. 2. refresh() behaves differently on current lock level. With NO LOCK it reads from Data Cache; on any stronger lock it hits the database. I am of the opinion that all refresh() must bypass data cache altogether always -- because refresh() seems to express explicit intent of the user to read data from database (say when the application thinks that out-of-band modifications may have taken place on the database). 3. There is an 'optimization' on BrokerImpl.refresh() -- one for a single entity and other for a collection. Removing that optimization (which leaves some maintenance concern of similar but not same code blocks) is another suggestion. Comments? -- View this message in context: http://www.nabble.com/datacache-tp17326391p17501042.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.