ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: CacheStore and CacheStoreAdapter questions.
Date Thu, 05 Feb 2015 17:51:30 GMT

I agree that Ignite implementation can be injected in a concrete subclass.
However, I disagree with adding setter for CacheStoreSession.  Having
setters on an interface looks a bit weird to me.

I believe we should either have an abstract class, or create
CacheStoreSessionResource and auto-inject it.

Thoughts? (Semyon, given that you have created the CacheStore class, what
do you think?)


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

> Folks,
> I do not understand why CacheStore is a class and not an interface, and why
> do we have another abstract class CacheStoreAdapter.
> As I see that CacheStore have two non-abstract methods:
>    - ignite() - gives access to injected Ignite instance. Used only in
>    JdbcCacheStore.
>    - session() - gives access to store session for TX cache. Used in dozens
>    places. It returns private "ses" field. This field is not annotated
> anyhow
>    and as I understand it is set somewhere in Ignite internals through
>    reflection.
> Both methods can be refactored as follows:
>    - ignite() must be removed. Protected annotated field with Ignite
>    instance must be added to JdbcCacheStore instead.
>    - session() method must be made abstract and another abstract method
>    session(CacheStoreSession) must be added. This way, we will set session
>    through interface method call instead of hard-coded reflective field
> update.
> This way we will be able to convert CacheStore to interface with minimum
> changes. It will significantly improve Ignite store extensibility (e.g. we
> already had to replace inheritance with composition for GridGain interop
> store what made code bigger and dirtier).
> Vladimir.

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