ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Lukyanov <stanlukya...@gmail.com>
Subject Deprecating LOCAL cache
Date Wed, 25 Jul 2018 07:52:24 GMT
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:
In particular, a recent SO question brought up the fact that LOCAL caches don’t support
native persistence:
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.

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
- On the page about cache modes explain that LOCAL is deprecated and can be replaced with
a PARTITIONED cache with a node filter


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message