<div dir="ltr">All the L1 data for a DIST cache is stored in the same data container as the actual distributed data itself. I wanted to propose breaking this out so there is a separate data container for the L1 cache as compared to the distributed data.<div>
<br></div><div style>I thought of a few quick benefits/drawbacks:</div><div><br></div><div style>Benefits:</div><div style>1. L1 cache can be separately tuned - L1 maxEntries for example<br></div><div style>2. L1 values will not cause eviction of real data</div>
<div style>3. Would make <a href="https://issues.jboss.org/browse/ISPN-3229">https://issues.jboss.org/browse/ISPN-3229</a> an easy fix</div><div style>4. Could add a new DataContainer implementation specific to L1 with additional optimizations</div>
<div style>5. Help with some concurrency issues with L1 without requiring wider locking (such as locking a key for an entire ClusteredGet rpc call) - <a href="https://issues.jboss.org/browse/ISPN-3197">https://issues.jboss.org/browse/ISPN-3197</a>.</div>
<div style><br></div><div style>Drawbacks:</div><div style>1. Would require, depending on configuration, an additional thread for eviction</div><div style>2. Users upgrading could have double memory used up due to 2 data containers</div>
<div style><br></div><div style>Both?:</div><div style>1. Additional configuration available<br></div><div style> a. Add maxEntires just like the normal data container (use data container size if not configured?)</div><div style>
b. Eviction wakeup timer? We could just reuse the task cleanup frequency?</div><div style> c. Eviction strategy? I would think the default data container's would be sufficient.</div><div style><br></div><div style>
I was wondering what you guys thought.</div><div style><br></div><div style>Thanks,</div><div style><br></div><div style> - Will</div></div>