Re: [infinispan-dev] State transfer testing
A quick note on @Merged: it isn't intended for use as a state merge mechanism. It is
just a notification. You can't really merge state unless you have some form of entry
versioning, and preferably a versioning scheme that is resilient to concurrent updates
such as a vector clock. And even then, you can only "fast-forward" in certain
cases, so the callback needs to be modified to handle the cases where there is a conflict.
Further, the API would need to change to handle this eventually consistent behaviour as
well (Pete and I are talking about this for JSR 347 too). Essentially an
EventuallyConsistentCache would have a signature for GET which looks a bit like:
EventuallyConsistentCache {
VersionedValue<V> get(K key) throws VersionConflictException;
void resolveVersionConflict(K key, Version correctVersion);
}
VersionConflictException extends CacheException {
Set<VersionedValue<V>> getConflictingVersions();
}
VersionedValue<V> {
V getValue();
Version getVersion();
}
Naturally, this adds overhead (memory) and performance (gc) so this eventually consistent
mode will be disabled by default.
Cheers
Manik
On 19 Jul 2011, at 18:44, Bela Ban wrote:
On 7/19/11 7:16 PM, Mircea Markus wrote:
> Agreed on the versioning for auto-merge. I'm just wondering weather it
wouldn't make more sense, for now, not to do any (incorrect) merge as we do now, but
stick with the old approach of
> migrating this responsibility to the user.
The old approach was (1) incorrect and (2) nobody ever implemented
@Merged to merge state !
(1): for example could a joiner transfer its state (null) to an existing
coordinator (not null state) !
The old approach was incorrect. The new approach still doesn't handle
merges, but at least it is consistent.
>> This is something we should discuss separately from the new rebalancing code.
Note that this also applies to replication, not only distribution.
> Just a note on state transfer with replication: 5.1's state transfer (REPL) uses
the rehashing code from distribution to move state around: the basic idea is that if
numOwners>clusterSize,
> when a node joins you practically have state transfer.
I see you still haven't given up on your old idea... :-)
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org