[infinispan-dev] Dropping AtomicMap/FineGrainedAtomicMap
Galder Zamarreño
galder at redhat.com
Mon Feb 10 03:58:26 EST 2014
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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
More information about the infinispan-dev
mailing list