On 19 June 2013 15:35, cotton-ben <ben.cot...@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@L1" > vs. get(K) probability of "readThrough@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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
