[infinispan-dev] conflicts resolution in DeltaAware

[Sanne Grinovero]

thanks for resuming this topic;
some more thoughts:

2011/4/20 Manik Surtani <manik at jboss.org>:
> I think changing the merging interface won't solve your problem since as others have pointed out, the AtomicMap is locked based on its key.  So you won't be able to have concurrent updates to the AtomicMap anyway.

I didn't delve yet into how Infinispan is managing locking, but it
seems every time we talk about it I get confused; sorry it seems my
assumptions don't match the implementation.
I have read
http://community.jboss.org/wiki/LockingandConcurrency
which states that Infinispan by default acquires locks lazily, i.e. at
transaction(batch) boundaries, possibly failing at this point if
that's not possible.
So assuming that OGM is never eagerly locking the AtomicMap, I'm going
to assume that the worst case the owner of such an atomic map would be
to receive two different update statements, one A'->A'' and one
A'->A'', so the owner should be able to figure out a different delta
to apply A'->A''' , if that's possible to apply both without
conflicts.
Of course I'd expect the AtomicMap being locked during the
transformation - very briefly on the owner side only - but I don't see
how the two delta commands are generating two lock commands, unless
we're talking about eager locking.

>
> Mircea's suggestion of a Cache instance instead of an AtomicMap is _conceptually_ correct, but practically, don't do it!  One Cache instance per entity is way overkill.

Yes I figured that, wasn't going to try it; BTW it would present the
same problem recursively as I would need to track them..

>
> Perhaps what you need is a different type of grouping structure, perhaps a FineGrainedMap, similar to an AtomicMap, which is locked based on a combination of map name and key accessed within the map.
>
> Would need to think about how this works with the rest of the locking code...

Yes please :)
I'm surprised nobody else expects this from an AtomicMap, nobody asked
for something similar during the relatively longer experience with
JBoss Cache using  the Tree API?

Cheers,
Sanne

>
> On 8 Apr 2011, at 18:07, 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 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
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>