cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Huss <johnth...@gmail.com>
Subject Re: ObjectCache
Date Thu, 09 Mar 2017 18:16:14 GMT
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 <lon.varscsak@gmail.com> 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 <johnthuss@gmail.com> wrote:
>
> > Right
> > On Wed, Mar 8, 2017 at 3:16 PM Musall, Maik <maik@selbstdenker.ag>
> 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 <johnthuss@gmail.com>:
> > > >
> > > > 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 <maik@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.reich@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 <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