ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Store manager and @CacheLocalStore questions.
Date Thu, 05 Feb 2015 19:53:42 GMT
Vova,

I agree with moving @CacheLocalStore annotation off of public API for now.
Please file a ticket in Jira, so we can address it later.

D.

On Thu, Feb 5, 2015 at 2:21 AM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Hi,
>
> Currently we have @CacheStoreManager annotation. By definition, it means
> that entries are stored in multiple node-local storages without a single
> global store. Such approach works correctly only if we store not only
> key-value, but entry version as well. Otherwise, it is possible that old
> cache values will overwrte new ones.
> To support this approach we also have CacheStoreManager.isLocal() method
> which alters behavior of regular store logic for local store in multiple
> places inside cache internal logic.
>
> We leave this annotation in public package in case user would like to
> implement his own local store. However, for now there is no way for him to
> understand how local store logic differs from regular store, unless he dig
> in pretty complex cache source code.
>
> And at the moment there is only one known implementation of this store -
> local file store from GridGain enterprise edition, which will not be
> open-sourced.
>
> I'd like to discuss several points:
> 1) Do we really want to keep local store concept in public package?
> 2) If yes, then we must make it usable. I see two ways to achieve this:
>
>    - Add verbose documentation to both @CacheStoreManager annotation and
>    CacheStore class on what happens if local store is defined.
>    - Or create another abstract class "CacheLocalStore extends CacheStore"
>    which will have other abstract methods with version in signatures, so
> that
>    it will be self-explanatory for user.
>
> 3) If no, then we may do the following:
>
>    - Refactor CacheStoreManager, so that it will always operate on key,
>    value and version.
>    - Provide default sotre manager implementation in Ignite which will
>    simply ignore version and work as a global store
>    - Create special store manager implementation for our local file store
>    in GridGain.
>    - Force cache to ask defined plugins for a store manager implementation
>    for defined store. If plugin has specific store manager implementation
> for
>    the sotre, return it. Otherwise, return *null*. If none plugin returned
>    store manager for the store, use default open-source implementation
> which
>    ignores versions.
>    - With this approach "local store" concept will go away from Ignite
>    completely.
>
>
> Comments are welcome.
>
> For now I moved @CacheLocalStore annotation from *o.a.i.cache.store* to
> *o.a.i.internal.processors.cache.store* package.
>
> Vladimir.
>

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