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 <m...@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.re...@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 > >
