[infinispan-dev] State transfer testing

[Manik Surtani]

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