[infinispan-dev] L1 Data Container

[Sanne Grinovero]

On 19 June 2013 15:35, cotton-ben <ben.cotton at alumni.rutgers.edu> wrote:
> /
>>> 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:
>> [...]
>> At the opposite site, I don't see how - as a user - I could optimally
> tune a separate container. /
>
> There is 1 place where this is important from the User's view.  Users want
> (and actually need) to be able to tune their expectations for their
> Cache/Grid provider's L1 capability join-point.  Specifically, a user can be
> greatly empowered if their provider provides an API that assist the user's
> preference for "where he wants to be" on the get(K) probability  of "hit at L1"
> vs. get(K) probability of "readThrough at remoteContainer" distribution curve.

Indeed, IFF you separate the two storage areas you get in that kind of
need, but I think it's an unnecessary complexity. The world is
actually quite simple: you have N gigs of heap available, you can
estimate you want your LIRS strategy to target some M number of
entries.
Which entries exactly, you will never be able to make a good choice,
but LIRS (or other eviction strategies) are able to make a decision
which is easy to model.

This whole discussion is starting from the assumption that it is
important to keep the owned entries in memory; I don't think we should
blindly assume that.
If someone could explain an important reason to always favour owned
entries over *hotter* entries I'd be less skeptical, but even so that
would be a step backwards in ease of configuration as today the grid
basically self-tunes ergonomically.

Sanne