Store manager and @CacheLocalStore questions.

[Vladimir Ozerov <vo...@gridgain.com>]

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.

Re: Store manager and @CacheLocalStore questions.

[Dmitriy Setrakyan <ds...@apache.org>]

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 <vo...@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.
>