[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