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 <vblagoje(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org