The delta’s will remain, but they’re each key/value pair. Example: say you want to store a dehydrated list of three elements (“one”, “two”, “three”) in Infinispan
Before you’d do (approx): key=my-list value=AtomicMap(k=1,v=“one”, k=2,v=“two”, k3=“v3”) Internally, we’d track deltas and only send those changes. What I propose we do is: key=1 (group=“my-list") value=“one” key=2 (group=“my-list") value=“two” key=3 (group=“my-list") value=“three” The delta’s are still there. Each changed key is sent separately, when it changes. This is not the final product of course. As agreed with Pedro, we’d need a way to have a view map for all key/value pairs associated with a given group, i.e. cache.getGroups(“my-list”). I know Sanne et al also need a way to have coarse grained locking on the entire group sometimes, as well as fine grained locking, so we’d need to find a way to accomodate that. Cheers, On 21 Jan 2014, at 21:42, Vladimir Blagojevic <vblag...@redhat.com> wrote: > I agree with Erik here. Deltas are used in M/R and I've never detected > any problems so far. > On 1/21/2014, 1:39 PM, Erik Salter wrote: >> Please don't remove the Delta stuff. That's quite useful, especially for >> large collections. >> >> Erik >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev