[infinispan-dev] fetchPersistentState and local cache store has some data

[Manik Surtani]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100308/ba22d5c0/attachment-0002.html