> The docs suggest(ed?) that local cache was local to that object context, but > it really ends up being global.
What is real? :) https://www.youtube.com/watch?v=-niPJMSeh34 It is local from the app perspective. Query cache is a common memory region that can be used by multiple contexts. Just like with Java heap, when an object goes out of scope, it is not immediately GC'd, but since it can be GC'd on demand, that memory is effectively available to the app. If the entries are not in use (and the cache is properly sized against available memory), expired or not, they will be removed automatically when you add more entries to the cache. In fact we decided against a "localized" implementation exactly because it has no upper boundary on memory consumption, so it was deemed unsafe in a real app. I guess it wouldn't hurt to build/document recipes for aggressive removal of expired entries (based on Caffeine or EhCache API). Though since my caches usually operate at 100% capacity and are constantly churned, I never felt a big need to do that. Andrus > On Apr 13, 2018, at 1:43 AM, Lon Varscsak <lon.varsc...@gmail.com> wrote: > > I agree, I had the same issue. The docs suggest(ed?) that local cache was > local to that object context, but it really ends up being global. I had a > couple of Caffeine solutions in place too that did bind it closer to the > EC. I've since scrapped that (not sure why) and it least ties the cache to > my web session, so I'm secure in knowing that at least they'll go away then. > > -Lon > > On Thu, Apr 12, 2018 at 12:06 PM, John Huss <johnth...@gmail.com> wrote: > >> My main problem was that the docs imply that locally cached things are tied >> to a single object context, giving the expectation that when the context >> goes away the locally cached things go away too. This is only superficially >> true -- indeed you can't access them anymore, but the objects are still in >> the cache taking up space. I can't see a benefit of having it work this >> way. >> >> This wouldn't be a problem if the cache was set to expire entries, but if >> you are only intending to use local caching you wouldn't think you need >> that. My contexts are all short lived and the cache is just a convenience >> to avoid having to keep passing a reference to a previously fetched object >> around while generating an HTTP response -- this is a good way to handle >> objects that you don't want to define an explicit relationship to, but >> still need to access occasionally. >> >> Additionally, the fact the the entire state of the object context is >> prevented from being garbage collected while these objects are in the cache >> makes the problem much worse if you happen to be fetching a lot of data, >> but only caching a small amount. >> >> On Thu, Apr 12, 2018 at 12:20 AM Andrus Adamchik <and...@objectstyle.org> >> wrote: >> >>> Yeah, LRU caches are prone to individual cache entry size fluctuations. >>> With large active caches this averages out (more or less), but is still >> an >>> issue. >>> >>> Somehow I overlooked Caffeine. Looks interesting. Let me try to switch a >>> few projects. >>> >>> Andrus >>> >>>> On Apr 12, 2018, at 6:45 AM, Aristedes Maniatis <a...@maniatis.org> >>> wrote: >>>> >>>> On 11/4/18 11:28pm, Andrus Adamchik wrote: >>>>> Also EhCache may actively remove expired items (?), but OSCache >>> certainly did not, and it was not a problem either, also because of >>> maxsize/LRU. >>>> >>>> Actually that's a problem in EHcache that had us leave it and use >>> Caffeine instead. EHCache only tries to clean up memory when you write a >>> new item to the cache and it is hardcoded to try and evict two items for >>> every new item you add. >>>> >>>> This is a real problem if you try to add a new 100Mb query result and >> it >>> happens to try to evict two 1kB queries already in the cache. Boom, your >>> app runs out of memory and dies. The response from the EHCache people was >>> that it works best when all items our roughly the same size. >> Unfortunately >>> the Cayenne query cache can easily add items with hugely different sizes. >>>> >>>> >>>> We found that caffeine gives us a little more control over this process >>> ( https://github.com/ben-manes/caffeine/wiki/Cleanup ) and it is still a >>> trivial replacement since it implements jCache. >>>> >>>> Caching is definitely not one of those "click this box to make >>> everything faster" and forget about it things. >>>> >>>> >>>> >>>> >>>> Oh, hi everyone. I know I've been absent for a while... my life has >> been >>> a little crazy. >>>> >>>> >>>> Ari >>> >>
