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
SHARED_CACHE...
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:
> http://cayenne.apache.org/doc/configuring-caching-behavior.html
>
> 2009/4/10 Lawrence Gerstley <lawger..cn.com>
>
>> 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
>> lawger..mail.com
>> 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
>>> <jfbaldwi..arthlink.net>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>
This archive was generated by hypermail 2.0.0 : Fri Apr 10 2009 - 09:10:10 EDT