[infinispan-dev] L1 Data Container

Mircea Markus mmarkus at redhat.com
Mon Jul 8 08:50:56 EDT 2013


On 19 Jun 2013, at 16:19, Sanne Grinovero <sanne at infinispan.org> wrote:

> On 19 June 2013 13:44, William Burns <mudokonman at gmail.com> 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
> 
> -1!
>  I don't think thats a benefit actually, from the point of view of a user:
> as a user I only know I have a certain amount of memory available on
> each node, and the application is going to use certain data way more
> often than others.
> The eviction strategy should be put in condition to be able to make an
> optimal choice about which entries - among all - are better kept in
> memory vs. passivated.
> I don't see a specific reason to "favour" keeping in memory owned
> entries over an L1 entry: the L1 entry might be very hot, and the
> owned entry might be almost-never read.
> Considering that even serving a Get operation to another node (as
> owners of the entry) makes the entry less likely to be passivated (it
> counts as a "hit"), the current design naturally provides an optimal
> balance for memory usage.
> 
> At the opposite site, I don't see how - as a user - I could optimally
> tune a separate container.

Very good points Sanne.

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list