[infinispan-dev] L1 Data Container

Paolo Romano romano at inesc-id.pt
Wed Jun 19 09:33:24 EDT 2013


That would make *a lot* of sense :)

Cheers,

     Paolo


On 6/19/13 1:44 PM, William Burns wrote:
> 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.
>
> I thought of a few quick benefits/drawbacks:
>
> Benefits:
> 1. L1 cache can be separately tuned - L1 maxEntries for example
> 2. L1 values will not cause eviction of real data
> 3. Would make https://issues.jboss.org/browse/ISPN-3229 an easy fix
> 4. Could add a new DataContainer implementation specific to L1 with 
> additional optimizations
> 5. Help with some concurrency issues with L1 without requiring wider 
> locking (such as locking a key for an entire ClusteredGet rpc call) - 
> https://issues.jboss.org/browse/ISPN-3197.
>
> Drawbacks:
> 1. Would require, depending on configuration, an additional thread for 
> eviction
> 2. Users upgrading could have double memory used up due to 2 data 
> containers
>
> Both?:
> 1. Additional configuration available
>    a. Add maxEntires just like the normal data container (use data 
> container size if not configured?)
>    b. Eviction wakeup timer?  We could just reuse the task cleanup 
> frequency?
>    c. Eviction strategy?  I would think the default data container's 
> would be sufficient.
>
> I was wondering what you guys thought.
>
> Thanks,
>
>  - Will
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130619/19be575e/attachment-0001.html 


More information about the infinispan-dev mailing list