cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Reich <markus.re...@markusreich.at>
Subject Re: ObjectCache
Date Fri, 24 Feb 2017 22:24:35 GMT
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 <maik@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.varscsak@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 <maik@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.reich@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
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message