On 19 Jun 2013, at 20:49, Sanne Grinovero <sa...@infinispan.org> wrote:
> On 19 June 2013 19:00, Dan Berindei <dan.berin...@gmail.com> wrote: >> >> >> >> On Wed, Jun 19, 2013 at 5:19 PM, Sanne Grinovero <sa...@infinispan.org> >> wrote: >>> >>> On 19 June 2013 13:44, William Burns <mudokon...@gmail.com> wrote: >>>> All the L1 data for a DIST cache is stored in the same data container as >>>> the >>>> actual distributed data itself. I wanted to propose breaking this out >>>> so >>>> there is a separate data container for the L1 cache as compared to the >>>> distributed data. >>>> >>>> I thought of a few quick benefits/drawbacks: >>>> >>>> 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: >>> as a user I only know I have a certain amount of memory available on >>> each node, and the application is going to use certain data way more >>> often than others. >>> The eviction strategy should be put in condition to be able to make an >>> optimal choice about which entries - among all - are better kept in >>> memory vs. passivated. >>> I don't see a specific reason to "favour" keeping in memory owned >>> entries over an L1 entry: the L1 entry might be very hot, and the >>> owned entry might be almost-never read. >>> >>> Considering that even serving a Get operation to another node (as >>> owners of the entry) makes the entry less likely to be passivated (it >>> counts as a "hit"), the current design naturally provides an optimal >>> balance for memory usage. >>> >>> At the opposite site, I don't see how - as a user - I could optimally >>> tune a separate container. >>> >>>> 2. L1 values will not cause eviction of real data >>> >>> -1 >>> That's not a benefit, as I explained above. "Real Data" is not less >>> important, especially if it's never used. >>> Granted I'm making some assumptions about the application having some >>> hot-data and some less hot data, and not being able to take advantage >>> of node pinning or affinity strategies.. but that is another way to >>> say that I'm assuming the user needs L1: if it was possible to apply >>> these more advanced strategies I'd disable L1 altogether. >>> >> >> You're also assuming that data can always be recreated from another source, >> but I don't think that's always the case. If Infinispan is the canonical >> data store and there is no cache store, you can't enable eviction for the >> "real data" and with a single container you can't enable eviction for the L1 >> entries either. > > Well spotted. True we are making many assumptions, I guess each of us > is having some use case in mind and designing for it. > While our configuration options are flexible, we can design to provide > an optimal structure for all combinations, especially as some > configuration options can be mixed in ways which would never be used > in a real-world solution. > > In the specific situation, if I where to use Infinispan as a > "canonical data store", and without having a cache store, I think I > would at the very least isolate it from its clients by using Hot Rod; > in such case L1 would be disabled for obvious reasons. +1 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
