Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
MIME-Version: 1.0
References: <CAGscxrzRH4TFHgMXkRw-RWFbyPTyT=bdra7rLz-Xcr=FvPU5SA@mail.gmail.com>
 <059088E3-0513-4391-BD3C-EC9AC94E56AE@selbstdenker.ag> <CALAw18x0A0JbQw+2zgE2RDbAygv_+hy7k49kxFqtbuy+211m8A@mail.gmail.com>
 <DA382FBC-DA50-4839-B71E-36FEB0F5DF52@selbstdenker.ag> <CAGscxrzHFy8gG93EEkh6jVwVqgYL7y=mf0do+bk8zXfPz1TSow@mail.gmail.com>
 <B382E66A-1856-4386-A2E6-F76700BB908A@selbstdenker.ag> <CAOUwSGv+DLvb8ohqkFxcRRNmEB0Rcuk3Oyze-PP37T_RL_6gjA@mail.gmail.com>
 <56910E23-F3C4-4337-B58D-DDFF76C38837@selbstdenker.ag>
In-Reply-To: <56910E23-F3C4-4337-B58D-DDFF76C38837@selbstdenker.ag>
From: John Huss <johnthuss@gmail.com>
Date: Wed, 08 Mar 2017 21:30:54 +0000
Message-ID: <CAOUwSGty4THLW6pAnPPqvHE8E6G7eH-MQB3-7rnC9Oz5uiRXOQ@mail.gmail.com>
Subject: Re: ObjectCache
To: user@cayenne.apache.org
Content-Type: multipart/alternative; boundary=001a114ebf3094cfe4054a3ed851
archived-at: Wed, 08 Mar 2017 21:31:11 -0000

--001a114ebf3094cfe4054a3ed851
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 databas=
e?
> >>
> >> 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 EO=
F
> 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 u=
se
> >>> 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 wou=
ld
> >>>> 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 ar=
e
> >> 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=E2=80=99s not uncommon for me to have a complex set of queries t=
o 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 th=
e
> >>>>> 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=E2=80=99t have to be aware of this from a code perspective.
> >>>>>
> >>>>> Where I=E2=80=99m still hung up, is that it=E2=80=99s common for me=
 to have many
> parts
> >> of
> >>>>> my code that are not aware of each other that display/operate on th=
e
> >> same
> >>>>> data, and I=E2=80=99m unsure how to update the cache (since there a=
re
> 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=E2=80=99t 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 t=
he
> >>>>>> 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-live=
d
> >>>>>> 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 d=
o
> >> 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.htm=
l
> >>>>>>>
> >>>>>>> In 4.0 docu I can't find anything
> >>>>>>>
> >>>>>>> br
> >>>>>>> Meex
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>

--001a114ebf3094cfe4054a3ed851--