I would be ok with disabling the shared cache except for a few entities. Is there a way with listeners to intercept queries for specific entities and return something manually and skip the query?
Using the query cache is great, except if you are firing relationships that weren't prefetched -- in that case you can't avoid using the shared cache and getting stale data. On Tue, Jun 27, 2017 at 8:39 AM Andrus Adamchik <[email protected]> wrote: > > > On Jun 21, 2017, at 4:10 PM, John Huss <[email protected]> wrote: > > > A cache shared between ObjectContexts has a fixed upper limit. 10000 is > the > > default maximum number of entries, which can be changed in the Modeler. A > > cache attached to each ObjectContext (also referred to as "local cache" > > elsewhere in this chapter), which only stores the objects that were > > accessed via this context, has no upper limit. > > This sounds about right, even in 4.0. > > > So there is a Shared cache and a Local cache. The default behavior for > > relationship faulting (lazy loading) is to place these objects into the > > *Shared* cache. Same with Cayenne.objectForPK. > > More generally, every query, implicit or explicit, would result in > selected objects placed in both shared cache and local cache of a given > context. > > > This can cause the shared cache to get large, and in some cases I've had > > objects that I really wanted to be cached forever to get pushed out of > the > > Shared cache by poorly written code that fires a ton of lazy > relationships. > > > > Also this can cause stale data to be returned when not carefully guarding > > against it with prefetches that refresh any needed relationships. > > > > I'd prefer that objects from lazily loaded relationships be placed in the > > *Local* cache to eliminate both of these problems. I really only want to > > ever use the Shared cache *explicitly*, never implicitly. So this > default > > behavior seems backwards to me. > > > > Is there a way to change this? > > Not easily. It is unmanaged (you can't set per-entity caching policies, > expiration times, etc.), and this is certainly a big limitation. Some > people turn it off completely by unchecking "Use Shared Cache" in the > Modeler, but that's another extreme. > > Having said that, I never bothered tweaking shared *object* cache, cause I > base all my refresh policies on *query* cache instead. Query cache is of > course fully configurable, and local vs shared can be specified explicitly. > So my typical approach is to leave object cache alone to do what it does > behind the scenes, but manage query cache that would update objects in the > shared cache as a side effect. > > Andrus
