ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Versioned entry scope usage
Date Fri, 31 Jul 2015 07:26:19 GMT
On Thu, Jul 30, 2015 at 11:56 PM, Denis Magda <dmagda@gridgain.com> wrote:

>
>
> 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?
>

I agree about IgniteCache.iterator(), however I disagree about
IgniteCache.localEntries(). Give that the latter method is local, we should
always be able to provide the version, so why not do it?

Btw, please don't forget to reflect this in the javadoc.


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

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