Dynamite. Thanks as always, Andrus. I'm going to get started with your
recommendation right away.
Lawrence
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
> 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 - 12:10:06 EDT