ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Semyon Boikov <sboi...@gridgain.com>
Subject Re: Removing methods from the Ignite cache entry API
Date Mon, 19 Jan 2015 08:47:25 GMT
+1 for simplification. In my opinion the only method on GridCacheEntry that
was really needed was method for setting custom ttl. Now custom ttl per
operation can be set using IgniteCache.withExpiryPolicy, so I think rich
GridCacheEntry API is not needed.

On Sat, Jan 17, 2015 at 11:26 PM, Sergi Vladykin <sergi.vladykin@gmail.com>
wrote:

> I'm for simplification. My experience with cache API says that there is
> almost no situation when you will need this smart entry. I used it may be
> once to set ttl as far as I remember. For me it looks preferable to have
> entry just like a dumb immutable container for key and value (plus for
> other related info).
> It was always very confusing part for me when for example you take entry in
> one thread, another thread concurrently removed it, put another value for
> the same key, is your entry in the first thread still valid? What behavior
> to expect when you call getValue()? What will happen if you are trying to
> perform some modifications on it? I can imagine many scenarios when it will
> not be obvious how the system will and how it should behave here.
>
> Sergi
>
>
> 2015-01-17 21:35 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>
> > Well,
> >
> > One of the disadvantages of rich APIs is that they are very hard to learn
> > due to massive amount of methods on them. On top of that, rich cache
> entry
> > API is still not rich enough to support all the IgniteCache API, so it is
> > still a subset.
> >
> > However, I completely agree with your point about a need to pass a
> context
> > or the cache instance itself. This is not convenient, and moreover, we
> > won't have full freedom to do it because of JCache spec.
> >
> > I have just noticed that most JCache APIs, including Cache and
> Cache.Entry,
> > have this method:
> > *<T> T unwrap(java.lang.Class<T> clazz);*
> >
> > How about we use these methods to replace the need for a context? For
> > example,
> > ----
> > *Ignite ignite = entry.unwrap(Ignite.class);*
> > *IgniteCache cache = entry.unwrap(IgniteCache.class);*
> > *IgniteCache.Entry entry = entry.unwrap(IgniteCache.Entry.class);*
> > ----
> >
> > Thoughts?
> >
> > D.
> >
> > On Sat, Jan 17, 2015 at 9:10 AM, Vladimir Ozerov <vozerov@gridgain.com>
> > wrote:
> >
> > > I think our rich entry concept is a good design because user do not
> have
> > to
> > > pass context (i.e. cache) to any place where he want to use the entry.
> > > Instead, entry encapsulates the cache.
> > > If we remove it, instead of simply passing GridCacheEntry between the
> > > methods, user will have to either pass both cache and key or bother
> with
> > > adding cache as a field to any class which is expected to use cache
> > > entries. The latter approach is not a problem with DI frameworks like
> > > Spring, but still yields in more code comparing to GridCacheEntry.
> > >
> > > Can we simply made our GridCacheEntry implementing JCache interface, so
> > > that user could cast/unwrap it to GridCacheEntry if absolute JCache
> > > implementation independence is not required?
> > >
> > >
> > >
> > > On Sat, Jan 17, 2015 at 6:14 PM, Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > wrote:
> > >
> > > > I want to get some opinions about IGNITE-96:
> > > > https://issues.apache.org/jira/browse/IGNITE-96
> > > >
> > > > Cache.Entry from JCache spec has a very small API and is, in fact,
> not
> > > much
> > > > different from Java Map.Entry. In GridGain however, the
> GridCacheEntry
> > > API
> > > > has many additional methods, mainly duplicating functionality from
> the
> > > > GridCache API.
> > > >
> > > > I personally like the JCache approach and don't think we need extra
> > > methods
> > > > on the cache entry API. User can always get this functionality from
> the
> > > > IgniteCache API.
> > > >
> > > > Can anyone think of a good reason to have additional methods on the
> > cache
> > > > entry API?
> > > >
> > > > D.
> > > >
> > >
> >
>

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