On Wed, Jun 19, 2013 at 11:56 AM, Sanne Grinovero <sanne@infinispan.org> wrote:
On 19 June 2013 16:44, cotton-ben <ben.cotton@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.
Actually this is only half true, we know that the values are hot on this node specifically.  Other nodes could be requesting the "cold" data quite frequently as well.  This could lead to L1 values pushing out distributed data leaving it where nodes have L1 cached values for which the owner doesn't even own.  And when the L1 cache value expires there will be no more backup (not including passivation).  This is a very odd situation though, since you can't do conditional operations then as well.

And even with separate containers this is possible to have the L1 discrepency, but actually having a lower lifespan would help remedy this since every once in a while the "hot" value would have to retrieved again from the owning node.

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.
The value cannot be disabled for the timeout.  Unless by disable you mean to increase the timeout so high that it will never be hit?  Is that a common use case? 

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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev