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.
yes, what I was looking for is a way to efficiently compare the state
of two partitions after a split brain. Is this your scenario?
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;
hmm, Delta.merge(DeltaAware) is only
invoked with lock held on the corresponding. Multiple tx won't be able to own that
lock at the same time. I might be wrong about this, but with transactions, I only see this
to be useful if multiple threads operate on the same key within the same transaction (this
is something we don't support atm).
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.
not sure it is atomic map you need then, as w access
to AM is serialized by acquiring lock on its key. If you want finer grained, per key
access, you might want to use a Cache and not an AtomicMap.
From my understanding of AtomicMap, if
two different keys are changed one transaction will fail (correct?).
the calls are
serialized and applied one at a time,(this is enforced by the locking) both should be
applied successfully.
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?
this optimisation might be doable: if a tx1 tries to write to a ATM that is
locked by tx2, if keys in tx1 do not overlap keys in tx2 then we can allow them both write
access. If there's an overlap serialise the access (current behaviour). This is very
similar to what the Cache's semantics though, and you might want to consider weather
you want a ATM here or a Cache.
Emmanuel, do you agree this would fit the HibernateOGM needs?
Cheers,
Sanne