[infinispan-dev] conflicts resolution in DeltaAware

[Galder Zamarreño]

On Apr 11, 2011, at 11:56 AM, Sanne Grinovero wrote:

> 2011/4/11 Galder Zamarreño <galder at redhat.com>:
>> On Apr 8, 2011, at 7:07 PM, Sanne Grinovero wrote:
>> 
>>> </snip>
>>> 
>>> As Emmanuel pointed out while implementing OGM, if two different
>>> updates are being applied to an AtomicMap, it's possible that the
>>> updates relate to different keys in the AtomicMap, and for the OGM
>>> usecase we would be totally fine with that and would *not* like the
>>> transaction to be rolled back. From my understanding of AtomicMap, if
>>> two different keys are changed one transaction will fail (correct?).
>>> Of course it's totally possible that both updates where going to
>>> affect the same keys, and in this case we want to have the operation
>>> rolled back.
>> 
>> I'm not sure I understand the need for changing the merge() method signature in DeltaAware. If I understand this correctly, it seems like what you really want is different locking granularity when atomic maps are used so that instead of being per key/value pair, when atomic maps are used, the granularity is key+atomicmap_key. This would at least require making AtomicHashMap thread safe because it currently works on the assumption that it's thread safe thanks to per cache key locking.
> 
> Right. I don't necessarily have to change the DeltaAware interface, as
> you say the lock granularity is what we need to improve. I assumed
> started by looking into DeltaAware, but if you have a better
> implementation to suggest I'm very interested.
> Would the Tree API benefit from this as well, or is this kind of
> locking the expected behaviour?

As far as the tree API is concerned, the documentation matches what the code does: http://community.jboss.org/wiki/TreeAPIModule#Locking_In_Tree_API - IOW, locks are acquired per node which is at the global atomic map level. Of course, if we implement this the tree API would benefit but the trade offs would need to be noted as well. I mean, if you wanna make locking per atomic map key, you'll have to relax the accuracy of things like size...etc.

In terms of implementation, I think there'd be two parts: on one side the locking interceptor would inspect the value part and based on that change the granularity of the lock to be on multiple union keys. Each union key would be formed of the cache key, and the atomic key which can be deducted from the delta, since the delta specifies the cache entries modified in the atomic map. So, if you're to put a brand new atomic map, you'd lock on all of them, and if you're updating, only on the delta keys. The other part, and potentially more complex, is to make the AtomicHashMap's delegate map concurrent, I mean the FastCopyHashMap.

> 
> Sanne
> 

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache