[infinispan-dev] conflicts resolution in DeltaAware

[Galder Zamarreño]

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.

> 
> 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