On 4 Mar 2010, at 10:12, Mircea Markus wrote:
Hi,
This is a discussion Galder and I started on the irc.
We son't currently have a well defined policy for what happens when
fetchPersistentState="true" and the node that receives state already has some
data in it, that might overlap with remotely received data.
Most of the loaders right now do a clear() now, before integrating any data. This is not
done by all the loaders: JdbmCacheStore, BdbjeCacheStore override this.
So some of the loaders do a mirror of the data(first they empty the store), some do an
override.
Correct behaviour should be:
1. Shared stores do not fetch persistent state at all.
2. Non-shared cache stores clear() and then apply retrieved persistent state.
Any impls that do not follow this pattern should be considered buggy and a JIRA should be
created accordingly. Perhaps this functionality could be in the AbstractCacheStore.
Mirror might make sense in at least one scenario: you have a cluster
running, each node having it's own local store. One node goes down and, after a while
you re-start it. This new node will integrate the persistent state of the others, and
entries might have been deleted in between (while the node was down). now, if these
deleted entries are in new joiner's store, this would mean data inconsistency.
This is why a clear() needs to happen before state is applied.
So I think we should:
- clearly define what happens with the existing data in the cache store during
fetchPersistentState
- if we decide to clear it before fetchPersistentState, we should call store.clear() from
StateTransferManager and not from particular cache store implementation, as this is error
prone
+1.
- we can even use a configurable strategy, e.g.
fetchPersistentState="none" fetchPersistentState="override"
fetchPersistentState="mirror"
I don't see the purpose of this "mirror" option?
Cheers,
Mircea
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org