ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanislav Lukyanov <stanlukya...@gmail.com>
Subject RE: Deprecating LOCAL cache
Date Wed, 25 Jul 2018 08:44:11 GMT
To me it also raises a question of having REPLICATED :)
But that might seem too radical, so let’s decide on the LOCAL first.

I don’t mind keeping LOCAL as an alias for PARTITIONED with a default node filter,
but I don’t see much benefit in it. Why to have a shortcut for something used by 1% (or
less?) when there is a way to do the same with a few more lines?
Compatibility is a reason to keep things as they are, but that’s why I suggest to only remove
it in 3.0 when we’ll have a chance to do some cleaning.

Stan

From: Valentin Kulichenko
Sent: 25 июля 2018 г. 11:09
To: dev@ignite.apache.org
Subject: Re: Deprecating LOCAL cache

It sounds like the main drawback of LOCAL cache is that it's implemented
separately and therefore has to be maintained separately. If that's the
only issue, why not keep LOCAL cache mode on public API, but implement it
as a PARTITIONED cache with a node filter forcefully set? That's similar to
what we do with REPLICATED caches which are actually PARTITIONED with
infinite number of backups.

This way we fix the issues described by Stan and don't have to deprecate
anything.

-Val

On Wed, Jul 25, 2018 at 12:53 AM Stanislav Lukyanov <stanlukyanov@gmail.com>
wrote:

> 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
>


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