cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lawrence Gerstley <>
Subject Re: Lifecycle Design
Date Fri, 10 Apr 2009 21:28:08 GMT
So, in my knowledge-gaining journey with this topic, I ran across this  
page:, which looks  
like a list of items yet to be done or at least yet to be documented  
(and boy, when I have things really understood, I want to volunteer  
some documentation time to the project). There is a topic headline of  
"Refresh All", and an indication in the links posted as to the  
"RefreshQuery", but the pertinent part of the links are broken, and I  
can't track down the resolution of the items. However, this is exactly  
what I need to do for a first step. My application's environment will  
be (mandated by the customer), a thick client running on a Citrix  
instance, and some of the challenges posed by JGroups will take me  
awhile to understand. In the meantime, I want to provide a simple  
"Refresh All" button that will provide for a dumb refresh without  
leaving the application. I'm struggling with different caching  
strategies, but a simple Refresh All would get me across the line for  
the moment. Is there any info on this?



On Apr 10, 2009, at 6:09 AM, Andrus Adamchik wrote:

> As mentioned in the quoted docs, there are ways to receive immediate  
> notifications on the individual objects updates (if they are updated  
> via Cayenne). This approach, while the most powerful on the surface,  
> is least practical, especially across the VM. It suffers from a  
> number of shortcomings (as also have been mentioned here):
> * It has a potential to generate too much network traffic
> * As all update events are broadcast, it has a potential to DDOS the  
> apps who may not care about 90% of the updates (as all incoming  
> events incur processing overhead), so some manual event channel  
> filtering may be needed.
> * It does not correctly refresh cached query lists. E.g. if you have  
> a cached fetch for "documents that are in draft mode", and then  
> received an event saying that one of the drafts has changed to "not  
> a draft", the object will be refreshed, the list will become stale,  
> as its composition no longer matches the search criteria.
> * Finally, the data can change in DB by non Cayenne clients...
> So I am very much in favor of the Query Cache approach that is not  
> documented that well, but is really simple to use:
>  query.setCacheStrategy(QueryCacheStrategy.LOCAL_CACHE); // or  
>  query.setCacheGroups("g1", "g2", ...);
> Once you start doing that for your queries, you can perform further  
> cache configuration in a semi-declarative manner. E.g. I am  
> successfully using OSQueryCacheFactory:
>  dataDomain.setQueryCacheFactory(new OSQueryCacheFactory());
> This ties Cayenne query cache to OSCache which allows time based  
> expiration of entries, cron like expressions, and forced  
> invalidation, including remote invalidation via JGroups. All of that  
> incurs nearly zero overhead, as the entries are not actively purged  
> from cache, but rather marked as invalid by "group" (see  
> 'setCacheGroups' above). Cross-VM events are also sent as the names  
> of the groups to invalidate, not full object snapshots. This is very  
> powerful and easy to use stuff.
> Andrus
> On Apr 10, 2009, at 10:17 AM, Andrey Razumovsky wrote:
>> The proposed way is to use JGroups or JMS for synchronization:
>> 2009/4/10 Lawrence Gerstley <>
>>> So, I have the same question here--multiple thick clients (desktop  
>>> RCP
>>> applications), each with a DataContext tied to the same backend, and
>>> potential database access (direct or otherwise) from other  
>>> toolsets out of
>>> my control. Is there a recommended strategy for refreshing each  
>>> applications
>>> singleton DataContext to stay in synch, or manually a supplying  
>>> refresh
>>> command to the DataContext to periodically update (and, if so, with
>>> what/how)?
>>> Kind regards,
>>> Lawrence
>>> ===================================
>>> Lawrence Gerstley, Ph.D.
>>> PSMI Consulting
>>> Cel: (415) 694-0844
>>> On Apr 8, 2009, at 4:22 PM, Malcolm Edgar wrote:
>>> Hi Joe,
>>>> Your singleton cache is going to need to be update periodically if
>>>> there are changes to the under lying database from other sources.
>>>> regards Malcolm Edgar
>>>> On Thu, Apr 9, 2009 at 7:45 AM, Joe Baldwin < 
>>>> >
>>>> wrote:
>>>>> I *think* this is a life-cycle question, but there may be more  
>>>>> to it.
>>>>> Proposed Design:
>>>>> 1. Standard Web page JSP using Tomcat server.
>>>>> 2. One of the JSP's accesses a singleton.
>>>>> 3. The singleton accesses and stores a database field via Cayenne
>>>>> (presumably when the class is initially loaded) and should never  
>>>>> need to
>>>>> access the field again.
>>>>> 4. I would prefer it if the database field change would be  
>>>>> propagated to
>>>>> the
>>>>> singleton upon the next new client-Session.
>>>>> Problem
>>>>> 1. Here is the odd bit: the database field can be modified via  
>>>>> direct
>>>>> access
>>>>> to the database (SQL, etc).
>>>>> 2. Cayenne appears not to see this change even when a new client- 
>>>>> Session
>>>>> is
>>>>> initialized.
>>>>> 3. I can *force* the singleton to recognize the change by  
>>>>> restarting
>>>>> Tomcat
>>>>> (but that is totally lame :) )
>>>>> 4. Unless I have made a mistake (which is possible), the  
>>>>> singleton should
>>>>> be
>>>>> only associated with JSP session scope.  But if I am wrong, this  
>>>>> could be
>>>>> the problem.
>>>>> Obviously, I have a misunderstanding about either Cayenne or  
>>>>> Tomcat
>>>>> caching
>>>>> or perhaps its a combo of the two.  It appears from my tests  
>>>>> that the
>>>>> singleton class may be constructed the first time after Tomcat is
>>>>> restarted
>>>>> and then remains persistent even across different sessions.
>>>>> Are there any suggestions as to a simple design in which my  
>>>>> singleton
>>>>> forces
>>>>> re-initialized (i.e. refresh the Cayenne object from the DBMS  
>>>>> data) upon
>>>>> each new session?
>>>>> Thanks,
>>>>> Joe

View raw message