[infinispan-dev] L1 Data Container

[Mircea Markus]

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

> On 19 June 2013 17:17, William Burns <mudokonman at gmail.com> wrote:
>> 
>> 
>> 
>> On Wed, Jun 19, 2013 at 11:56 AM, 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.
>> 
>> 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.
> 
> I see where you're coming from, but my point is the opposite: if other
> nodes would be requesting this data quite frequently, it woudln't be
> considered "cold": by using a single data container the eviction
> strategy automatically takes this into account as well. A hit is a hit
> in all senses.
> 
>> 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.
> 
> That's just another excellent reason to keep a unified datacontainer:
> if a different node uses the value frequently, allow it to be cached
> for read operations, even if the primary owner is passivating it.
> Write operations are inherently safe as they have to go through the
> owner and trigger entry activation as needed.
+1

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