From dev-return-6409-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Tue Oct 09 18:06:07 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 44320 invoked from network); 9 Oct 2007 18:06:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Oct 2007 18:06:06 -0000 Received: (qmail 34723 invoked by uid 500); 9 Oct 2007 18:05:53 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 34697 invoked by uid 500); 9 Oct 2007 18:05: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 34688 invoked by uid 99); 9 Oct 2007 18:05:53 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Oct 2007 11:05:53 -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 plinskey@gmail.com designates 209.85.162.179 as permitted sender) Received: from [209.85.162.179] (HELO el-out-1112.google.com) (209.85.162.179) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Oct 2007 18:05:57 +0000 Received: by el-out-1112.google.com with SMTP id s27so354733ele for ; Tue, 09 Oct 2007 11:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=M3at/3LkTNNUretnleKIdEaoIpWMtlry6xC8ng4ITAk=; b=DFtRaBbsfRSXTZQh1aQNkr+RAfRo+FiMxQsQyMnESGzTaXGM310qH5/9d6FYnxxGsExqKoAS6t9V5symBI/c8C3pPJ7a0TC6buCZgwy5sKSe3z5ZUye4X/y0xH/o8BVOSkz/kqXnN6VHumhOheRVeINlBWXcNOrFSEDs6lpfDQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ga/78Fd6S0NvoHPkbKOL9K9hQiZzRXlmle+0Mn10bbHzhAYZBT3DVU1kf+AxtmN+9C5gtZXIKr9D8wa+PH7Cc0NNDdx6y5fidnxE7DvJ5YfcPpioLJ5jCKHwrIsyk+T+ZvrSNzybhGzRmuGVUYF+Abbibfcw9CeAqvSVJ0m2w9Y= Received: by 10.142.233.9 with SMTP id f9mr3670871wfh.1191953135492; Tue, 09 Oct 2007 11:05:35 -0700 (PDT) Received: by 10.143.165.19 with HTTP; Tue, 9 Oct 2007 11:05:35 -0700 (PDT) Message-ID: <7262f25e0710091105t247b404bw870ad6b05107a20c@mail.gmail.com> Date: Tue, 9 Oct 2007 11:05:35 -0700 From: "Patrick Linskey" To: dev@openjpa.apache.org Subject: Re: em.refresh() semantics In-Reply-To: <89c0c52c0710090746v55842a09y334a9b13cc1847@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <89c0c52c0710041359y6158eecbqf5261df9f1fc3362@mail.gmail.com> <3992B07C0590B548BB294D31768A1DA2802040@repbex01.amer.bea.com> <89c0c52c0710041532y60155f24y8e691b642423228a@mail.gmail.com> <89c0c52c0710090746v55842a09y334a9b13cc1847@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Sounds like a new issue. Can you link it to the existing issue though? Maybe mark it as a sub-task? -Patrick On 10/9/07, Kevin Sutter wrote: > Okay, I'm narrowing in on this problem. It seems to be related to the > automatic runtime enhancement. Given my simple update to the > TestPersistence testcase that I posted earlier to this thread and not > statically pre-enhancing the Entities will easily reproduce the problem. It > seems that the automatic PC subclassing is not properly detecting updates to > the Entities and, thus, when we do a refresh(), there's nothing to indicate > that the Entity is dirty and, thus, no reload from the database. > > If I change the scenario and do the pre-enhancement, then the setting of the > attributes on AllFieldTypes and NamedEntity will properly dirty the Entities > and they will be reloaded when the refresh() is invoked. > > Is this one of the known limitations with the automatic runtime enhancement > or is a JIRA Issue required to track this problem? > > Thanks, > Kevin > > On 10/4/07, Kevin Sutter wrote: > > > > Pinaki, > > No caching is turned on. The only cache that I am aware of that is turned > > on by default is the Query Compilation Cache. All other caches need to be > > explicitly configured. I have not configured for any caches. I am running > > with the standard "test" persistence unit definition in our > > persistence.xml file. > > > > Kevin > > > > On 10/4/07, Pinaki Poddar wrote: > > > > > > Is L2 cache configured for this experiment? If datacache is active, then > > > that the state may be delivered from there itself without hitting the > > > database. > > > Does the test behave differently, if you set > > > a) datacahe off > > > or b) evict from both L1 and L2 cache before refresh? > > > To ensure that em.evict() acts on L2 cahce too, please set > > name="openjpa.BrokerImpl" value="EvictFromDataCache=true"/> > > > > > > Pinaki Poddar > > > 972.834.2865 > > > > > > > > > >-----Original Message----- > > > >From: Kevin Sutter [mailto:kwsutter@gmail.com] > > > >Sent: Thursday, October 04, 2007 3:59 PM > > > >To: dev@openjpa.apache.org > > > >Subject: em.refresh() semantics > > > > > > > >Hi, > > > >From reading the spec and the Pro EJB 3 book, I was under the > > > >impression that a call to em.refresh() would refresh from the > > > >database regardless. No questions asked. But, I am finding > > > >that we don't work that way. I made a simple update to our > > > >simple PersistenceTest using the AllFieldTypes (non-versioned) > > > >and NamedEntity (versioned) objects. And, neither one will > > > >load when refresh() is called. For some reason, with the > > > >AllFieldTypes, none of the fields are being detected as being > > > >updated. And, with the NamedEntity, since the version field > > > >hasn't been updated, then it doesn't refresh the rest of the object. > > > > > > > >From my reading, this doesn't sound like proper processing. > > > >But, before I start making any changes, I'm looking for > > > >alternate interpretations of the spec. Thanks. > > > > > > > >I've attached a patch for PersistenceTest, if you are > > > >interested in trying it out. > > > > > > > >Kevin > > > > > > > > > > > > > > Notice: This email message, together with any attachments, may contain > > > information of BEA Systems, Inc., its subsidiaries and affiliated > > > entities, that may be confidential, proprietary, copyrighted and/or > > > legally privileged, and is intended solely for the use of the individual or > > > entity named in this message. If you are not the intended recipient, and > > > have received this message in error, please immediately return this by email > > > and then delete it. > > > > > > > > -- Patrick Linskey 202 669 5907