cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musall, Maik" <m...@selbstdenker.ag>
Subject Re: ObjectCache
Date Wed, 08 Mar 2017 20:00:47 GMT
Can someone confirm this? Will I always get fresh data from DB with an explicit query, or am
I at risk being returned stale data from a context-local cache that doesn't even see changes
that haven been recorded in the shared snapshot cache in the meantime, let alone in the database?

I'm still a bit puzzled and out of documentation about the question of how to control data
freshness. Cayenne seems to be a bit different than EOF in this regard, with it's multi-level
caching.

Maik


> Am 24.02.2017 um 23:24 schrieb Markus Reich <markus.reich@markusreich.at>:
> 
> I think if you start a "standard" query it goes always against the DB, this
> would be the query cache but this is not implicit done, you have to use
> groups for that.
> Object cache as I understand works behind the scenes, when you access
> properties of you persistent entity with getters, then values where read
> through the GraphManager from Cache.
> Only OID Queries and RelationalQueries can get their data from cache.
> Standard SelectQuery always runs a query on DB. But maybe I'm wrong :-/
> 
> Musall, Maik <maik@selbstdenker.ag> schrieb am Fr., 24. Feb. 2017 um
> 23:14 Uhr:
> 
>> Hi Lon,
>> 
>> so with a context-local cache, you would still execute a regular query,
>> but that query would not actually hit the database but the cache would
>> return the result instead? Is it like a result set per query SQL string
>> which is cached? I don't really understand how those local caches are keyed.
>> 
>> If there is any Cayenne documentation explaining this which I missed, I'd
>> be happt to get a pointer to that.
>> 
>> Maik
>> 
>>> Am 24.02.2017 um 18:25 schrieb Lon Varscsak <lon.varscsak@gmail.com>:
>>> 
>>> I built something similar in EOF to local cache, so I think I can answer
>> at
>>> least part of the question.
>>> 
>>> It’s not uncommon for me to have a complex set of queries to do something
>>> like compute pricing on an order.  Rather than having to maintain many
>> tiny
>>> caches or ivars with query results, all of my code executes queries to
>> get
>>> the data set it needs whenever the pricing calculation is called.  It
>> makes
>>> the code simpler, but gives you the performance of having stored the
>>> results yourself in an ivar (or dictionary).
>>> 
>>> Add in EHCache and now you can control how long those objects live
>> (rather
>>> than the life of an ivar). If they get removed from cache due to cache
>>> control settings, the next time through the code, it will refetch them
>> but
>>> I don’t have to be aware of this from a code perspective.
>>> 
>>> Where I’m still hung up, is that it’s common for me to have many parts of
>>> my code that are not aware of each other that display/operate on the same
>>> data, and I’m unsure how to update the cache (since there are multiple
>>> local caches) in between those two components after commit (since change
>>> propagation is turned off by default and even when on is in a separate
>>> thread so I can’t assume the objects will be refreshed when I need).
>>> 
>>> -Lon
>>> 
>>> On Fri, Feb 24, 2017 at 3:00 AM, Musall, Maik <maik@selbstdenker.ag>
>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I'd like to extend this question a bit. I just read the entire
>> performance
>>>> tuning chapter again [1], and I'm a bit puzzled especially about the
>>>> ObjectContext's local caches, which Andrus also recommended to use in
>> the
>>>> "A way to refreshObject()" thread:
>>>> 
>>>>> So instead of micro-optimizations with shared snapshot cache, you
>> should
>>>> use queries with cache groups and query cache. They get refetched when a
>>>> cache group is flushed in response to an object commit. So technically
>> you
>>>> are not reusing the snapshot cache, but it really doesn't matter. The
>>>> benefit you get in code simplicity, consistency, and often performance,
>>>> always outweighs that. Besides this approach is cluster-friendly.
>>>> 
>>>> Coming from EOF I grew the habit of frequently creating short-lived
>>>> ObjectContexts, so basically every page load uses it's own new
>>>> ObjectContext to get fresh data from the shared global cache, because
>> other
>>>> users may have altered data between page loads. While working on a
>> page, I
>>>> have references to the objects that I need there anyway, so I don't
>>>> understand at all what that context-local cache mechanism should do for
>> me,
>>>> unless that "create new contexts all the time" strategy is just plain
>> wrong
>>>> for Cayenne-based applications?
>>>> 
>>>> And even if I would use a longer-lived ObjectContext for something,
>> where
>>>> would that local cache get in effect? Either I have references to
>> objects
>>>> anyway, or I would need to refetch them, which would go through to the
>>>> database, right? In what case would I get a benefit from a local cache?
>> I
>>>> didn't find answers to this in the Cayenne Guide.
>>>> 
>>>> Thanks
>>>> Maik
>>>> 
>>>> [1] https://cayenne.apache.org/docs/4.0/cayenne-guide/
>>>> performance-tuning.html <https://cayenne.apache.org/
>>>> docs/4.0/cayenne-guide/performance-tuning.html>
>>>> 
>>>> 
>>>>> Am 23.02.2017 um 09:43 schrieb Markus Reich <
>> markus.reich@markusreich.at
>>>>> :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I'm looking for a more detailed explaination of the caching mechanism,
>> as
>>>>> we are running a quite important and big web application with cayenne,
>> I
>>>>> want to fine tune, because we run in some performance issues.
>>>>> 
>>>>> I only found this
>>>>> https://cayenne.apache.org/docs/3.0/individual-object-caching.html
>>>>> 
>>>>> In 4.0 docu I can't find anything
>>>>> 
>>>>> br
>>>>> Meex
>>>> 
>>>> 
>> 
>> 


Mime
View raw message