Vladimir, do we have a ticket for cross-cache transactions with LOCAL cache? I can't find it. In my task I met this situation in tests and I want to fail such tests with link to this ticket. Also documentation in readme.io say nothing about cross-cache failures with LOCAL cache.
ср, 25 июл. 2018 г., 13:55 Stanislav Lukyanov <stanlukya...@gmail.com>: > 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 < > stanlukya...@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 > > > >
