Eviction for size limited back tier of a near cache?

[javafanboy]

We are looking at a use-case where we would need a "near cache" but cant let the distributed partitioned back cache (spread over multiple VMs) grow indefinitely. We would rather want the whole near cache to be size limited. I am well aware of how to create size limited front caches and how eviction can be configured etc. Now I am trying to understand how this works for partitioned, distributed back caches....

As I read the documentation you can configure the back tier to be partitioned and specify max size (in bytes), eviction policy etc. that will then apply per partition rather than for the whole back cache tier - i.e. if we for some reason would get a "hot partitions" with lots of inserts this could result in frequent evictions in that partition while other partitions still holds much less used objects that may not be evicted?! This would be ok in our case as load (both read and write) will be well distributed over partitions - what I really would like to confirm is how eviction in this type of size limited back tier relates to the front tier of the near cache? I.e. will the evicted objects also be removed from the front tier and if so is this synchronous or asynchronous?

I find the Coherence documentation quite ok for the individual elements that can be used to defines caches but it is not always easy to understand what combinations that are actually allowed or what the effect of combining them will be for instance related to eviction/invalidation etc...

[rstafford]

One refinement: the max cache size applies per storage member, not per partition. If a storage member’s contents for a cache reach the configured max size, and a prune happens, evicting some entries, those evictions will be replicated asynchronously to near caches assuming the all, auto, or present invalidation strategy<https://docs.oracle.com/en/middleware/standalone/coherence/14.1.1.2206/develop-applications/cache-configuration-elements.html#GUID-40E68653-6662-49BF-94A4-50008BB9BFBF__BABFEFIB> is configured. Cheers. From: javafanboy ***@***.***> Date: Wednesday, April 10, 2024 at 9:50 PM To: oracle/coherence ***@***.***> Cc: Subscribed ***@***.***> Subject: [External] : [oracle/coherence] Eviction for size limited back tier of a near cache? (Discussion #119) We are looking at a use-case where we would need a "near cache" but cant let the distributed partitioned back cache (spread over multiple VMs) grow indefinitely. We would rather want the whole near cache to be size limited. I am well aware of how to create size limited front caches and how eviction can be configured etc. Now I am trying to understand how this works for partitioned, distributed back caches.... As I read the documentation you can configure the back tier to be partitioned and specify max size (in bytes), eviction policy etc. that will then apply per partition rather than for the whole back cache tier - i.e. if we for some reason would get a "hot partitions" with lots of inserts this could result in frequent evictions in that partition while other partitions still holds much less used objects that may not be evicted?! This would be ok in our case as load (both read and write) will be well distributed over partitions - what I really would like to confirm is how eviction in this type of size limited back tier relates to the front tier of the near cache? I.e. will the evicted objects also be removed from the front tier and if so is this synchronous or asynchronous? I find the Coherence documentation quite ok for the individual elements that can be used to defines caches but it is not always easy to understand what combinations that are actually allowed or what the effect of combining them will be for instance related to eviction/invalidation etc... — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/oracle/coherence/discussions/119__;!!ACWV5N9M2RV99hQ!PIAtkb5ZHpxo5ZmvneDz8102WmtLjJUj_dR_pRSbcUgkXcXpsNanS1i2SsXhdzUC2p1CEc6ohWogcSGvC9ZK4CCIzn7e$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AA7BOJINC5NCPQ73E3QQT2TY4YB6ZAVCNFSM6AAAAABGBRRMQCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGQ4DSNRVHE__;!!ACWV5N9M2RV99hQ!PIAtkb5ZHpxo5ZmvneDz8102WmtLjJUj_dR_pRSbcUgkXcXpsNanS1i2SsXhdzUC2p1CEc6ohWogcSGvC9ZK4Hle1xSv$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[javafanboy]

Wow that was a quick reply - will try this out - Thanks!!!!