Details
-
Task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
3.1M2
-
None
Description
Now that CAY-1445 is in place and QueryCache is DI-managed, we can optimize the cache management and improve the API. We may open subtasks as we proceed with implementation:
1. Predictable memory use: The idea is to use a single query cache object per stack and allocate "subspaces" within this cache for individual ObjectContext local caches. This will ensure more predictable memory use in an application, as a single cache size policy will cover the entire application. We have a previously unused org.apache.cayenne.cache.NestedQueryCache class that implements this concept. (per CAY-1445 we started using it for the first time for nested contexts ... we'll see how successful it is). We can use it for top level ObjectContexts, and maybe think how to optimize key mapping.
2. More generic cache interface. There's a possible benefit of refactoring QueryCache API to use a more generic put/get that takes a String key instead of QueryMetadata. That simplifies implementing Cayenne cache on top of a general purpose cache used by a given application (I had to deal with this issue myself). This may also take us closer to building a single cache (single storage-wise) for objects and lists.
Attachments
Issue Links
- relates to
-
CAY-1602 OSCache clustering should be shared per JVM - @CacheGroup annotation causes creation of too many cluster listeners
- Closed