Hi Igniters, I’d like to start a discussion about the deprecation of the LOCAL caches.
LOCAL caches are an edge-case functionality I haven’t done any formal analysis, but from my experience LOCAL caches are needed very rarely, if ever. I think most usages of LOCAL caches I’ve seen were misuses: the users actually needed a simple HashMap, or an actual PARTITIONED cache. LOCAL caches are easy to implement on top of PARTITIONED If one requires a LOCAL cache (which is itself questionable, as discussed above) it is quite easy to implement one on top of PARTITIONED cache. A node filter of form `node -> node.id().equals(localNodeId)` is enough to make the cache to be stored on the node that created it. Locality of access to the cache (i.e. making it unavailable from other nodes) can be achieved on the application level. LOCAL caches are hard to maintain A quick look at the open issues mentioning “local cache” suggests that this is a corner case for implementation of many Ignite features: https://issues.apache.org/jira/issues/?jql=text%20~%20%22local%20cache%22%20and%20%20project%20%3D%20IGNITE%20and%20status%20%3D%20open In particular, a recent SO question brought up the fact that LOCAL caches don’t support native persistence: https://stackoverflow.com/questions/51511892/how-to-configure-persistent-storage-for-apache-ignite-cache Having to ask ourselves “how does it play with LOCAL caches” every time we write any code in Ignite seems way to much for the benefits we gain from it. Proposal Let’s deprecate LOCAL caches in 2.x and remove them in 3.0. As a part of deprecation let’s do the following: - Put @Deprecated on the CacheMode.LOCAL - Print a warning every time a LOCAL cache is created - Remove all mentions of LOCAL caches from readme.io, if any, except for the page about cache modes - On the page about cache modes explain that LOCAL is deprecated and can be replaced with a PARTITIONED cache with a node filter Thanks, Stan
