From dev-return-6407-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Tue Oct 09 14:54:27 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 56770 invoked from network); 9 Oct 2007 14:54:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Oct 2007 14:54:26 -0000 Received: (qmail 56879 invoked by uid 500); 9 Oct 2007 14:46:33 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 56847 invoked by uid 500); 9 Oct 2007 14:46:33 -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 56813 invoked by uid 99); 9 Oct 2007 14:46:33 -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 07:46:33 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of kwsutter@gmail.com designates 64.233.162.239 as permitted sender) Received: from [64.233.162.239] (HELO nz-out-0506.google.com) (64.233.162.239) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Oct 2007 14:46:35 +0000 Received: by nz-out-0506.google.com with SMTP id i11so900791nzh for ; Tue, 09 Oct 2007 07:46:14 -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:references; bh=mUgmf8ShABrplzsKCPR2KrLO19riOwjOSWkuIhHVZQg=; b=JlI2Bay1VzNxaPzIcyW2wf2ikf8gvsBhRuvPInWUD+CgxIATy1oDkSCnHq4dQ3s852re4uh9cuCg8QuhJWoPXV9p8rTuAlhNxYKlu03PmJems5IYOqcoNBoFaZiTtiFkdETgvG0oIiMXEQBd5+ogwQKu4G4W+9o1EDYs3wnMCFE= 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:references; b=GdcRxjwJS/YCtfn4pP2B3dedacmpVtsYv9y78eJU4Zma3Sx3d51QQiP/IhUSuBzDkkqvK4LiGGga4P8eKozbSXzOFBrBOysZ/07gWQRWgfmJjrgmdKq7NHO2Jocw9XlR8KvoW3k9J5pLTFd3x+OQpfnE6TrgzKaQjI4ISmoeu3Y= Received: by 10.115.23.12 with SMTP id a12mr4787203waj.1191941172530; Tue, 09 Oct 2007 07:46:12 -0700 (PDT) Received: by 10.114.75.15 with HTTP; Tue, 9 Oct 2007 07:46:12 -0700 (PDT) Message-ID: <89c0c52c0710090746v55842a09y334a9b13cc1847@mail.gmail.com> Date: Tue, 9 Oct 2007 09:46:12 -0500 From: "Kevin Sutter" To: dev@openjpa.apache.org Subject: Re: em.refresh() semantics In-Reply-To: <89c0c52c0710041532y60155f24y8e691b642423228a@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5502_30596031.1191941172521" References: <89c0c52c0710041359y6158eecbqf5261df9f1fc3362@mail.gmail.com> <3992B07C0590B548BB294D31768A1DA2802040@repbex01.amer.bea.com> <89c0c52c0710041532y60155f24y8e691b642423228a@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_5502_30596031.1191941172521 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. > > > > ------=_Part_5502_30596031.1191941172521--