[infinispan-dev] L1 Data Container

[Sanne Grinovero]

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.

Sanne

>
> However, for the /typical/ user's completeness requirements, this FACT
> probably won't be relevant.
>
>
>
> --
> View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-L1-Data-Container-tp4027447p4027463.html
> Sent from the Infinispan Developer List mailing list archive at Nabble.com.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev