Can someone confirm this? Will I always get fresh data from DB with an explicit query, or am I at risk being returned stale data from a context-local cache that doesn't even see changes that haven been recorded in the shared snapshot cache in the meantime, let alone in the database?
I'm still a bit puzzled and out of documentation about the question of how to control data freshness. Cayenne seems to be a bit different than EOF in this regard, with it's multi-level caching. Maik > Am 24.02.2017 um 23:24 schrieb Markus Reich <[email protected]>: > > I think if you start a "standard" query it goes always against the DB, this > would be the query cache but this is not implicit done, you have to use > groups for that. > Object cache as I understand works behind the scenes, when you access > properties of you persistent entity with getters, then values where read > through the GraphManager from Cache. > Only OID Queries and RelationalQueries can get their data from cache. > Standard SelectQuery always runs a query on DB. But maybe I'm wrong :-/ > > Musall, Maik <[email protected]> schrieb am Fr., 24. Feb. 2017 um > 23:14 Uhr: > >> Hi Lon, >> >> so with a context-local cache, you would still execute a regular query, >> but that query would not actually hit the database but the cache would >> return the result instead? Is it like a result set per query SQL string >> which is cached? I don't really understand how those local caches are keyed. >> >> If there is any Cayenne documentation explaining this which I missed, I'd >> be happt to get a pointer to that. >> >> Maik >> >>> Am 24.02.2017 um 18:25 schrieb Lon Varscsak <[email protected]>: >>> >>> I built something similar in EOF to local cache, so I think I can answer >> at >>> least part of the question. >>> >>> It’s not uncommon for me to have a complex set of queries to do something >>> like compute pricing on an order. Rather than having to maintain many >> tiny >>> caches or ivars with query results, all of my code executes queries to >> get >>> the data set it needs whenever the pricing calculation is called. It >> makes >>> the code simpler, but gives you the performance of having stored the >>> results yourself in an ivar (or dictionary). >>> >>> Add in EHCache and now you can control how long those objects live >> (rather >>> than the life of an ivar). If they get removed from cache due to cache >>> control settings, the next time through the code, it will refetch them >> but >>> I don’t have to be aware of this from a code perspective. >>> >>> Where I’m still hung up, is that it’s common for me to have many parts of >>> my code that are not aware of each other that display/operate on the same >>> data, and I’m unsure how to update the cache (since there are multiple >>> local caches) in between those two components after commit (since change >>> propagation is turned off by default and even when on is in a separate >>> thread so I can’t assume the objects will be refreshed when I need). >>> >>> -Lon >>> >>> On Fri, Feb 24, 2017 at 3:00 AM, Musall, Maik <[email protected]> >> wrote: >>> >>>> Hi all, >>>> >>>> I'd like to extend this question a bit. I just read the entire >> performance >>>> tuning chapter again [1], and I'm a bit puzzled especially about the >>>> ObjectContext's local caches, which Andrus also recommended to use in >> the >>>> "A way to refreshObject()" thread: >>>> >>>>> So instead of micro-optimizations with shared snapshot cache, you >> should >>>> use queries with cache groups and query cache. They get refetched when a >>>> cache group is flushed in response to an object commit. So technically >> you >>>> are not reusing the snapshot cache, but it really doesn't matter. The >>>> benefit you get in code simplicity, consistency, and often performance, >>>> always outweighs that. Besides this approach is cluster-friendly. >>>> >>>> Coming from EOF I grew the habit of frequently creating short-lived >>>> ObjectContexts, so basically every page load uses it's own new >>>> ObjectContext to get fresh data from the shared global cache, because >> other >>>> users may have altered data between page loads. While working on a >> page, I >>>> have references to the objects that I need there anyway, so I don't >>>> understand at all what that context-local cache mechanism should do for >> me, >>>> unless that "create new contexts all the time" strategy is just plain >> wrong >>>> for Cayenne-based applications? >>>> >>>> And even if I would use a longer-lived ObjectContext for something, >> where >>>> would that local cache get in effect? Either I have references to >> objects >>>> anyway, or I would need to refetch them, which would go through to the >>>> database, right? In what case would I get a benefit from a local cache? >> I >>>> didn't find answers to this in the Cayenne Guide. >>>> >>>> Thanks >>>> Maik >>>> >>>> [1] https://cayenne.apache.org/docs/4.0/cayenne-guide/ >>>> performance-tuning.html <https://cayenne.apache.org/ >>>> docs/4.0/cayenne-guide/performance-tuning.html> >>>> >>>> >>>>> Am 23.02.2017 um 09:43 schrieb Markus Reich < >> [email protected] >>>>> : >>>>> >>>>> Hi, >>>>> >>>>> I'm looking for a more detailed explaination of the caching mechanism, >> as >>>>> we are running a quite important and big web application with cayenne, >> I >>>>> want to fine tune, because we run in some performance issues. >>>>> >>>>> I only found this >>>>> https://cayenne.apache.org/docs/3.0/individual-object-caching.html >>>>> >>>>> In 4.0 docu I can't find anything >>>>> >>>>> br >>>>> Meex >>>> >>>> >> >>
