[infinispan-dev] conflicts resolution in DeltaAware

[Sanne Grinovero]

2011/4/11 Galder Zamarreño <galder at redhat.com>:
> On Apr 8, 2011, at 7:07 PM, Sanne Grinovero wrote:
>
>> Hi Mircea,
>> I remember you recently mentioned that you have been looking into ways
>> to give the ability to the application to resolve updating conflicts.
>> I don't think you where referring to AtomicMap or any other DeltaAware
>> specifically, but it seems now that we urgently need something like
>> this in OGM.
>>
>> I'm looking into the Delta interface, which defines this single method:
>>
>> DeltaAware merge(DeltaAware d);
>>
>> This looks great to merge an update onto an existing value; But of
>> course the world is made of parallel executing updates, especially so
>> when transactions are involved, so we would like to be able to deal
>> with multiple concurrent updates being applied on the same read value.
>>
>> I'm wondering if we could get something like
>>
>> DeltaAware merge(DeltaAware originalValue, DeltaAware updateA,
>> DeltaAware updateB) throws UnsolvableConflict;
>>
>> 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?

Sanne

>
>>
>> I don't mean the API I wrote literally, I wrote it like that just to
>> give a general picture of what we need; I'm not really liking the idea
>> of throwing an exception on a potentially frequently occurring event,
>> and also while you could chain such invocations in case of multiple
>> updates arriving on the same key, I think it would be far better to be
>> able to try different combinations - or let the application try to be
>> clever - to try resolving as much non conflicting DeltaAware updates
>> as possible.
>>
>> Considering that each transaction might change multiple keys, it would
>> be awesome to describe the API in such a way that either Infinispan or
>> the application can be "smart" and be able to estimate which
>> transaction could be removed (rolled back) to provide the minimum
>> amount of rolled back transactions. I'm not even sure the policy
>> should favour the maximum amount of transactions, maybe the
>> application wants to favour the highest possible changeset, or a
>> specific important one.
>>
>> Even if we start just implementing the method signature I proposed,
>> that could bring a hell of scalability improvements; possibly not only
>> to HibernateOGM but as far as I understood the TreeCache as well.
>>
>> Ideas?
>>
>> Emmanuel, do you agree this would fit the HibernateOGM needs?
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>