[infinispan-dev] L1 Data Container

[Mircea Markus]

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

> On 19 June 2013 16:44, cotton-ben <ben.cotton at alumni.rutgers.edu> wrote:
>> 
>> />>    At the opposite site, I don't see how - as a user - I could optimally
>>>>   tune a separate container.
>> 
>>> I agree that is more difficult to configure, this was one of my points as
>>> both a drawback and benefit.   It > sounds like in general you don't
>>> believe the benefits outweigh the drawbacks then./
>> 
>> Hi William.  The benefits of your ambition to provide  L1 capability
>> enhancements -- for /certain/ user's completeness requirements-- definitely
>> outweigh the drawbacks . This is a FACT.
> 
> I have to disagree ;-) It certainly is a fact that he's very well
> intentioned to make enhancements, but I don't this strategy is proven
> the be superior; I'm actually convinced of the opposite.
> 
> We simply cannot assume that the "real data" and the L1 stored entries
> will have the same level of hotness, it's actually very likely (since
> you like stats) that the entries stored in L1 are frequently accessed,
> to the opposite of other entries which - for as far as we know - could
> be large and dormant for years.
> 
> Storing useless data in memory is going to force to evict entries from
> L1 which are hot by definition (as they wouldn't be in L1 otherwise -
> as you pointed out there likely is an expiry) is a strategy which
> actively strives towards a less efficient storage.
> 
> Also L1 timeout can be disabled, making for a very nice self-tuning
> adaptive system.
+1

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