Return-Path: 
 <cayenne-user-return-1200-apmail-incubator-cayenne-user-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cayenne-user-archive@locus.apache.org
Received: (qmail 16997 invoked from network); 25 Sep 2006 14:02:52 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 25 Sep 2006 14:02:52 -0000
Received: (qmail 55186 invoked by uid 500); 25 Sep 2006 14:02:46 -0000
Delivered-To: apmail-incubator-cayenne-user-archive@incubator.apache.org
Received: (qmail 55175 invoked by uid 500); 25 Sep 2006 14:02:46 -0000
Mailing-List: contact cayenne-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cayenne-user-help@incubator.apache.org>
List-Unsubscribe: <mailto:cayenne-user-unsubscribe@incubator.apache.org>
List-Post: <mailto:cayenne-user@incubator.apache.org>
List-Id: <cayenne-user.incubator.apache.org>
Reply-To: cayenne-user@incubator.apache.org
Delivered-To: mailing list cayenne-user@incubator.apache.org
Received: (qmail 55152 invoked by uid 99); 25 Sep 2006 14:02:45 -0000
Received: from idunn.apache.osuosl.org (HELO idunn.apache.osuosl.org)
 (140.211.166.84)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Sep 2006 07:02:45 -0700
Authentication-Results: idunn.apache.osuosl.org
 smtp.mail=andrus@objectstyle.org; spf=permerror
X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=
Received-SPF: error (idunn.apache.osuosl.org: domain objectstyle.org from
 64.124.179.102 cause and error)
Received: from [64.124.179.102] ([64.124.179.102:56968]
 helo=polatsk.objectstyle.org)
	by idunn.apache.osuosl.org (ecelerity 2.1.1.8 r(12930)) with ESMTP
	id 40/98-13750-961E7154 for <cayenne-user@incubator.apache.org>;
 Mon, 25 Sep 2006 07:02:29 -0700
Received: (qmail 22255 invoked from network); 25 Sep 2006 14:01:53 -0000
Received: from unknown (HELO ?J???????????????IPv6:::1?) (127.0.0.1)
  by localhost with SMTP; 25 Sep 2006 14:01:53 -0000
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <B6C595D9-A26D-44C9-A37B-4C9C6EAAB0D7@ish.com.au>
References: <4517CE61.5010007@tiscali.it>
 <B6C595D9-A26D-44C9-A37B-4C9C6EAAB0D7@ish.com.au>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <395395C9-704B-4CD4-AB31-A3992958C559@objectstyle.org>
Content-Transfer-Encoding: 7bit
From: Andrus Adamchik <andrus@objectstyle.org>
Subject: Re: Caching query results
Date: Mon, 25 Sep 2006 10:01:53 -0400
To: cayenne-user@incubator.apache.org
X-Mailer: Apple Mail (2.752.2)
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Until 3.0 invalidating query lists was totally up to the developer.

In 3.0 we added three things - RefreshQuery (mentioned by Ari),  
"query cache group" concept, and pluggable QueryCache. This makes  
clustering and refresh policy management much simpler. I am running  
this latest code (3.0 trunk essentially) in pre-production  
environment on a cluster using OSQueryCache and it work extremely well.

I am going to document it better at some point (maybe even write an  
article). For now please post on the list if you have more questions  
about that. Essentially I do something like this:

dataDomain.setQueryCacheFactory(new OSQueryCacheFactory());

and then configure "oscache.properties" with group refresh policies  
(see OSQueryCache javadocs and OSCache framework documentation for  
details).

Once you have this set up, you can build in more bells and whistles  
if you wish. For instance I implemented the following extensions on a  
customer project:

* a web console for interactive cache group invalidation on the cluster.
* hooks to invalidate certain groups when certain entities are  
modified by the user via another new 3.0 feature - callbacks (I am  
going to write an overview of callbacks soon).

Andrus


On Sep 25, 2006, at 9:34 AM, Aristedes Maniatis wrote:
>
> On 25/09/2006, at 10:41 PM, Francesco Fuzio wrote:
>
>> <<It is important to understand that caching of *result lists* is  
>> done independently from caching of *individual DataObjects and  
>> DataRows*. Therefore the API is different as well. Also cached  
>> results lists _are not synchronized across VMs (even the shared  
>> cache)._>>_
>>
>> _So it seems that if my application is deployed in a cluster I  
>> have to implement a custom _distributed_ invalidation mechanism.
>
> It depends on how important it is that the data is up to date. One  
> solution might be to add functionality to Cayenne which invalidates  
> objects in the cache after a certain period of time (for instance 1  
> hour). It is now possible to invalidate objects one at time (http:// 
> cwiki.apache.org/confluence/display/CAYDOC/RefreshQuery)
>
> We are examining the same problem in our application (not a web  
> cluster, but a client/server application). For now we switched off  
> caching, but we need to think through the issues. One solution is  
> to implement a distributing messaging system to send notifications  
> between clients - I think Andrus was looking at XMPP at one time  
> (http://www.xmpp.org/summary.html) for this. Certainly it would be  
> handy if a messaging system was built into Cayenne for this. It  
> would also be useful for things like pessimistic locking.
>
>
> Ari Maniatis
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001   fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>
>