Yes, but an ObjectSelect will not rely on the snapshot cache - it can't. On Thu, Mar 9, 2017 at 11:46 AM Lon Varscsak <[email protected]> wrote:
> Hmm, are you sure John? I agree that the Objects won’t be in any object > cache, but won’t the data be in the snapshot cache (just like EOF)? > > On Wed, Mar 8, 2017 at 2:30 PM, John Huss <[email protected]> wrote: > > > Right > > On Wed, Mar 8, 2017 at 3:16 PM Musall, Maik <[email protected]> > wrote: > > > > > And unless I'm explictly creating a query cache somewhere in my > > > application, > > > I won't have one? > > > > > > > Am 08.03.2017 um 22:05 schrieb John Huss <[email protected]>: > > > > > > > > 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 <[email protected]> > > > 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 < > > > [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 > > > >>>>>> > > > >>>>>> > > > >>>> > > > >>>> > > > >> > > > >> > > > > > > > > >
