[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