If you have a reference to the cache, you could call the following in order to make sure that the clear was only local:
I'm not 100% sure about the timing of the @MergeEvent wrt the state transfer of data though.
Thanks for the response, that works a treat.
I had done the same by getting the data container (getDataContainer()) and clearing that but your way looks better.
I think you're right about the state transfer, it works fine on caches with few records. However, if I stress my test setup with 90000 records across 2 caches (One replicated, one distributed) with backing stores, I sometime see inconsistent caches where records are missing. I assume the clear is still processing when the state transfer starts (and are therefore wiped). Is there any way to delay the state transfer? Or force it to happen at some known point?
Are there any other recommended ways of handling the state merge?
Thanks again for your help,
If you focus only in the distributed cache for a sec, you could implement @DataRehashed annotated method and do the clear when the event.isPre=true. This even gets sent before any rehashing happens.
Thanks for that suggestion but I am seeing the @DataRehashed event after a @ViewChanged event so I don't think we can use that...
Did you try doing the clearing in @ViewChanged then?
The @ViewChanged event gets fired on any view change, including new nodes joining. I don't want to be clearing the cache on a new new node joining...Only on the merge.
I think this is also related to
@dex Yes, ISPN-1586 is certainly related conceptually - you could regard each joiner with preexisting data in the cache store as a partition re-joining the cache. However, handling these situations is quite different.
@Matthew The local node won't send any data before @DataRehashed ends. On the other hand the local node will still accept data from the other partitions, so your clear() call may delete more than necessary.
I think we don't have a proper solution for your problem at the moment. You could probably do it by hacking JGroupsTransport to call your code before the other listeners, so that our internal listener only ever called after you do the clear(), but that has its own share of risks (and may stop working in 5.2).
Please create an issue for this, although we certainly won't have full conflict resolution for merges in 5.2 we should give you the chance to just clear the local data store before sending or receiving anything.