You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Markus Reich <ma...@markusreich.at> on 2017/02/23 08:43:31 UTC
ObjectCache
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
Re: ObjectCache
Posted by Lon Varscsak <lo...@gmail.com>.
Ah, okay, cool.
On Thu, Mar 9, 2017 at 11:16 AM, John Huss <jo...@gmail.com> wrote:
> 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 <lo...@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 <jo...@gmail.com> wrote:
> >
> > > Right
> > > On Wed, Mar 8, 2017 at 3:16 PM Musall, Maik <ma...@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 <jo...@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 <ma...@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 <ma...@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
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>
Re: ObjectCache
Posted by John Huss <jo...@gmail.com>.
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 <lo...@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 <jo...@gmail.com> wrote:
>
> > Right
> > On Wed, Mar 8, 2017 at 3:16 PM Musall, Maik <ma...@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 <jo...@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 <ma...@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 <ma...@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
> > > >>>>>>
> > > >>>>>>
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> > >
> > >
> >
>
Re: ObjectCache
Posted by Lon Varscsak <lo...@gmail.com>.
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 <jo...@gmail.com> wrote:
> Right
> On Wed, Mar 8, 2017 at 3:16 PM Musall, Maik <ma...@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 <jo...@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 <ma...@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 <ma...@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
> > >>>>>>
> > >>>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>
Re: ObjectCache
Posted by John Huss <jo...@gmail.com>.
Right
On Wed, Mar 8, 2017 at 3:16 PM Musall, Maik <ma...@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 <jo...@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 <ma...@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 <ma...@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 <ma...@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
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: ObjectCache
Posted by "Musall, Maik" <ma...@selbstdenker.ag>.
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 <jo...@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 <ma...@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 <ma...@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 <lo...@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 <ma...@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
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: ObjectCache
Posted by John Huss <jo...@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 <ma...@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 <ma...@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 <lo...@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 <ma...@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
> >>>>
> >>>>
> >>
> >>
>
>
Re: ObjectCache
Posted by "Musall, Maik" <ma...@selbstdenker.ag>.
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 <ma...@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 <ma...@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 <lo...@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 <ma...@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
>>>>
>>>>
>>
>>
Re: ObjectCache
Posted by Markus Reich <ma...@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 <ma...@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 <lo...@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 <ma...@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
> >>
> >>
>
>
Re: ObjectCache
Posted by "Musall, Maik" <ma...@selbstdenker.ag>.
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 <lo...@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 <ma...@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
>>
>>
Re: ObjectCache
Posted by Lon Varscsak <lo...@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 <ma...@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
>
>
Re: ObjectCache
Posted by "Musall, Maik" <ma...@selbstdenker.ag>.
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 <ma...@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