[infinispan-dev] L1 Data Container

[Mircea Markus]

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

> 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.

+1

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