ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Versioned entry scope usage
Date Fri, 31 Jul 2015 06:56:26 GMT

On 7/30/2015 10:16 PM, Valentin Kulichenko wrote:
> On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
>> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <dmagda@gridgain.com> wrote:
>>> Igniters,
>>> I've been working on the task that will let the user to retrieve version
>>> related information for a particular Cache.Entry object.
>>> All the details are here:
>> https://issues.apache.org/jira/browse/IGNITE-946
>>> VersionedEntry of a given Cache.Entry can be retrieved by a call to
>>> 'Cache.Entry.unwrap(VersionedEntry.class)'.
>>> I've already fully supported 'unwrap' for Cache.Entry when it is returned
>>> from:
>>> - Cache.invoke();
>>> - Cache.invokeAll();
>>> - IgniteCache.randomEntry();
>>> The following entry points are left:
>>> - Cache.iterator();
>>> - IgniteCache.localEntries().
>>> However, I doubt that it makes sense to support these two last methods.
>>> In my understanding a use case scenario of VersionedEntry is the
>>> following: the user get a VersionedEntry for a particular key(s) using
>>> Cache.invoke, keeps it and then compares with other VersionEntries for
>> the
>>> same key retrieved later.
>>> I don't think that the user will iterate over a cache using
>>> Cache.iterator() or IgniteCache.localEntries() in order to get a version,
>>> especially in production.
>> Denis, what is the reason for not supporting a version on an entry at all
>> times? Is there a specific performance issue or slow down you are concerned
>> with?
>  From my understanding, version is available only on the node where the
> entry is stored and we never send it to client (for performance reasons
> obviously). For example, in continuous query you can acquire version in the
> remote filter, but not in local listener.
Seems that you are correct. Cache.iterator() relies on 
GridCacheQueryManager.scanIterator() that is, as I understand, is 
executed on every node and returns iterators containing keys and values.

If we want to support VersionedEntry for Cache.iterator() then we need to:
- transfer an entry version along with a key and value;
- rework GridCacheQueryManager.scanIterator();

This will affect the performance cause we will start transferring more 
data. Plus, I doubt that the user will use Cache.iterator() in 
production to get an entry version.
So I don't see any value by supporting VersionedEntry for 
Cache.iterator() and voting for not doing this. Objections, other opinions?


>>> What do you think? Do you see any other real life scenarios I'm missing?
>>> --
>>> Denis

View raw message