From dev-return-15362-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Wed Mar 03 17:13:29 2010 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 92246 invoked from network); 3 Mar 2010 17:13:28 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 3 Mar 2010 17:13:28 -0000 Received: (qmail 13934 invoked by uid 500); 3 Mar 2010 17:13:21 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 13912 invoked by uid 500); 3 Mar 2010 17:13:21 -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 13904 invoked by uid 99); 3 Mar 2010 17:13:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Mar 2010 17:13:21 +0000 X-ASF-Spam-Status: No, hits=2.2 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 209.85.220.226 as permitted sender) Received: from [209.85.220.226] (HELO mail-fx0-f226.google.com) (209.85.220.226) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Mar 2010 17:13:15 +0000 Received: by fxm26 with SMTP id 26so1730840fxm.33 for ; Wed, 03 Mar 2010 09:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=n3j+YNFtjrM7HRVm/kWzNXsC8Pn6VbKIeKJZInLxOOI=; b=tyBr2+OU2uTLTX/mMrYGRmYKZnyKxu7EOrguqL0jFNggPKIwi5TnsxlEHZUqECXNSG ubcfuAhHhXOvliIBg+bnLQuKk6YA5PWH8fSpcdwcS1tOabZiEY//x/DYR7QkdB9dDqK4 cXeUotLHP3g5TEYr+SKnl26rXSk6ghX/BUlnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=uFSwr/KikBy92HTk7LyV9h/uGDk0IkawfX6HspZp/qzJOdg67tn3ul74fZLMN/yra+ nwu6h3+S2b5vXjXhJGLxqFMoEUJnOWa+56+sG5HMOXLnH/plxatdOWHZFs/ZqeDUG+gs S2yvNgkj+dJIL3xP/TrXIMV+BI7l1fRLbLvZU= MIME-Version: 1.0 Received: by 10.223.110.29 with SMTP id l29mr1285470fap.64.1267636373190; Wed, 03 Mar 2010 09:12:53 -0800 (PST) In-Reply-To: References: <2122587191.37891267630347146.JavaMail.jira@brutus.apache.org> <86a010f4-83af-45ee-afe4-e5d07afce86b@default> Date: Wed, 3 Mar 2010 11:12:51 -0600 Message-ID: <89c0c52c1003030912i6259980eu145f1a34830a0506@mail.gmail.com> Subject: Re: [jira] Commented: (OPENJPA-1511) Executing a cached query doesn't properly cache results after DataCache eviction From: Kevin Sutter To: dev@openjpa.apache.org Content-Type: multipart/alternative; boundary=001636c59874bae34f0480e8978b --001636c59874bae34f0480e8978b Content-Type: text/plain; charset=ISO-8859-1 For historical reasons, I think this discussion needs to be in the JIRA... But, I'll let one you to summarize and get the JIRA updated appropriately... Given the additional description of the scenario, I also question the validity of the scenario. We should only update the L2 cache upon a commit or a re-read from the database (going to and from the database). Expecting dangling L1 entities to automatically populate the L2 cache is beyond the scope of the cache capability (IMHO). So, what if we modify the scenario and use Ravi's suggestion of evicting both the L1 and L2 items. Then, when accessing the query results, we should have to go against the database and get the L2 cache re-populated. I'm assuming this works correctly... Kevin On Wed, Mar 3, 2010 at 10:42 AM, Rick Curtis wrote: > The more I think about this, the more unsure I am of what the correct > answer > is. Perhaps someone else on the dev list has some input? > > Is the test that I've posted to OPENJPA-1511 a valid test? > > -- > Thanks, > Rick > > On Wed, Mar 3, 2010 at 10:32 AM, Ravi Palacherla < > ravi.palacherla@oracle.com > > wrote: > > > Hi Rick, > > > > I have a question about the following comment: > > >> * Execute a cached query which will return [E1]. This *should* result > > in [E1] being placed back in the L2 cache, but it isn't. > > > > When [E1] is in L1cache then what is the need to check L2 cache ? > > > > It is only when [E1] is missing in L1cache is when it tries to fetch from > > L2cache. > > At this time as L2cache does not contain [E1] it goes to DB and > re-populate > > L2cache with [E1]. > > > > Regards, > > Ravi. > > > > -----Original Message----- > > From: Rick Curtis (JIRA) [mailto:jira@apache.org] > > Sent: Wednesday, March 03, 2010 8:32 AM > > To: dev@openjpa.apache.org > > Subject: [jira] Commented: (OPENJPA-1511) Executing a cached query > doesn't > > properly cache results after DataCache eviction > > > > > > [ > > > https://issues.apache.org/jira/browse/OPENJPA-1511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840696#action_12840696 > ] > > > > Rick Curtis commented on OPENJPA-1511: > > -------------------------------------- > > > > I don't think that calling Cache.evict() should also remove an Entity > from > > the L1 cache. The javadoc for javax.persistence.Cache.evict(..) doesn't > > mention anything about removing the provided Entity from the persistence > > context. > > > > I think the problem here is as follows: > > * Entity [E1] is in the L2 cache and is managed by the current > persistence > > context (L1 cache). > > * Evict [E1] from the L2 cache. [E1] is still in the L1 cache. > > * Execute a cached query which will return [E1]. This *should* result in > > [E1] being placed back in the L2 cache, but it isn't. > > > > Make sense? > > > > > Executing a cached query doesn't properly cache results after DataCache > > eviction > > > > > > -------------------------------------------------------------------------------- > > > > > > Key: OPENJPA-1511 > > > URL: > https://issues.apache.org/jira/browse/OPENJPA-1511 > > > Project: OpenJPA > > > Issue Type: Bug > > > Affects Versions: 2.0.0-beta > > > Reporter: Rick Curtis > > > Assignee: Ravi P Palacherla > > > Attachments: TestCache.java > > > > > > > > > When doing some testing I found that the QueryCache sometimes doesn't > put > > results into the DataCache. > > > I haven't had time to debug the problem, but I'm opening this JIRA so I > > can attach the test case I've created. > > > The test scenario is as follows: > > > String query = "Select t FROM Item t where 1=1 ORDER BY t.id"; > > > items = em.createQuery(query,Item.class).getResultList(); > > > assertTrue(storeCache.contains(Item.class, items.get(0).getId())); > > > // Make sure that all of the results are in the DataCache. > > > for(Item o : items){ > > > assertTrue(storeCache.contains(Item.class, o.getId())); > > > } > > > storeCache.evict(Item.class,items.get(0).getId()); > > > // Evict one result > > > assertFalse(storeCache.contains(Item.class,items.get(0).getId())); > > > > > > // Executing the same query should re-populate the datacache > > > items = em.createQuery(query,Item.class).getResultList(); > > > assertTrue(storeCache.contains(Item.class, items.get(0).getId())); // > > fails here > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > --001636c59874bae34f0480e8978b--