Hello Ilya, Isn’t the cache name itself sufficient to make all the validations? The cache name is a unique parameter.
Furthermore, we do not check CacheConfiguration settings provided by the client if CacheConfiguration.name is already deployed when the client tries to get a reference to the cache (Ignite.getOrCreateCache(cacheCfg)). Don’t think we should make any exception for the restart scenarios. — Denis > On Oct 11, 2017, at 5:20 AM, Ilya Kasnacheev <ilya.kasnach...@gmail.com> > wrote: > > Hello Igniters! > > I'm working on IGNITE-2766. We want caches opened on client to survive > cluster restart (all nodes down, then some nodes up). Currently Ignite > compares deploymentId which will not match with new cluster's caches. > > But still we want to make sure it's still the same cache in the new > cluster, and not a different one with the same name. One obvious idea is to > look at CacheConfiguration. However I think a frequent scenario for cluster > restart is a minor change of cache configuration (e.g. add or remove > backup), and it will be a pity to lose client caches in this case. > > So, what fields in CacheConfiguration should we compare upon to figure out > if it's still the same cache? Name obviously. How does grpName work and > should we compare on them too? > > indexedTypes[] make sense because if it's a cache on different types it's > not safe to be used where it was open. cache mode and atomicity mode make > sence since cache should now be handled differently? > > Any other fields in CacheConfiguration we should check because it's not > safe to continue in case of mismatch? Some different approach? Suggestions > are kindly welcome > > -- > Ilya Kasnacheev
