Yes, I think now expire time can be calculated once when ExpiryPolicy is invoked and there is no need to store TTL in GridCacheMapEntry.
On Mon, Feb 16, 2015 at 6:08 PM, Vladimir Ozerov <[email protected]> wrote: > I'm wrong. Not TTL, but expire time. We do have to pass TTL over wire to > handle time difference on nodes, but why do we have to pass expire time? > Ideally we have to calculate expire time only once: when entry is submitted > to GridCacheTtlManager. Will it work? > > On Mon, Feb 16, 2015 at 6:01 PM, Vladimir Ozerov <[email protected]> > wrote: > > > Ok, what about removing TTL from cache completely? Given that we removed > > ttl()/expireTime() methods from public API, it appears that this concept > is > > not needed anymore. We only need to know expire time to remove the entry > > from cache. > > > > On Mon, Feb 16, 2015 at 5:54 PM, Semyon Boikov <[email protected]> > > wrote: > > > >> We have special 'expiry policy projection' > (IgniteCache.withExpiryPolicy) > >> and expiration can be set per-entry, so I think it isn't possible to > >> implement DR change you suggest. > >> > >> On Mon, Feb 16, 2015 at 5:39 PM, Vladimir Ozerov <[email protected]> > >> wrote: > >> > >> > One more question - do we still need TTL in cache? I have a feeling > >> that it > >> > is possible to remove it from cache completely, isn't it? > >> > > >> > On Mon, Feb 16, 2015 at 5:30 PM, Vladimir Ozerov < > [email protected]> > >> > wrote: > >> > > >> > > Hi, > >> > > > >> > > Currently our data center replication code in Ignite depends on the > >> fact > >> > > that DR engine will pass explicit TTL and expire time for each cache > >> > entry. > >> > > This is so because earlier in GridGain it was possible to set > separate > >> > TTL > >> > > for each cache entry. > >> > > > >> > > With the latest changes we have one ExpiryPolicy per cache. > Therefore, > >> > all > >> > > entries will have the same expiration logic. I think we can remove > >> > explicit > >> > > TTL and expire time from DR logic with the following assumptions: > >> > > 1) By default receiver cache will apply it's own expiration policy > for > >> > > entries from remote cache assuming that caches in both data centers > >> have > >> > > the same expiration logic. > >> > > 2) If it is necessary to define different expiration policy for > remote > >> > > cache, it could be overriden in cache plugin (separate method will > be > >> > added > >> > > to DR manager). > >> > > > >> > > This will remove lot's of spaghetty-like code from Ignite and will > >> reduce > >> > > DR entry size by 16 bytes. > >> > > > >> > > Any objections in this? > >> > > > >> > > Vladimir. > >> > > > >> > > >> > > > > >
