Re: ObjectCache

["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

[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

[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

[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

[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

["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

[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
> >>>>
> >>>>
> >>
> >>
>
>