Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openjpa.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Date: Tue, 09 Oct 2007 10:54:25 -0700
From: Marina Vatkina <Marina.Vatkina@Sun.COM>
Subject: Re: em.refresh() semantics
In-reply-to: <89c0c52c0710090746v55842a09y334a9b13cc1847@mail.gmail.com>
Sender: Marina.Vatkina@Sun.COM
To: dev@openjpa.apache.org
Message-id: <470BC051.6060006@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <89c0c52c0710041359y6158eecbqf5261df9f1fc3362@mail.gmail.com>
 <3992B07C0590B548BB294D31768A1DA2802040@repbex01.amer.bea.com>
 <89c0c52c0710041532y60155f24y8e691b642423228a@mail.gmail.com>
 <89c0c52c0710090746v55842a09y334a9b13cc1847@mail.gmail.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414

Kevin,

Shouldn't refresh() ignore the state of an entity? How would an EM know if the 
data in the database has changed or not?

thanks,
-marina

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 <kwsutter@gmail.com> 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 <ppoddar@bea.com> 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 <property
>>>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.
>>>
>>
>>
>