Unless you are using a query cache then running an ObjectSelect will always give you fresh data from the DB. On Wed, Mar 8, 2017 at 3:01 PM Musall, Maik <m...@selbstdenker.ag> wrote:
> 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 <markus.re...@markusreich.at > >: > > > > 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 <m...@selbstdenker.ag> 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 <lon.varsc...@gmail.com>: > >>> > >>> 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 <m...@selbstdenker.ag> > >> 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 < > >> markus.re...@markusreich.at > >>>>> : > >>>>> > >>>>> 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 > >>>> > >>>> > >> > >> > >
