So, in my knowledge-gaining journey with this topic, I ran across this
page: http://cayenne.apache.org/doc/refreshquery.html, 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?
Cheers,
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 <lawg...@rcn.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
lawg...@gmail.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 <jfbald...@earthlink.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
