Versioned entry scope usage

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Versioned entry scope usage

Denis Magda
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.

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

--
Denis
Reply | Threaded
Open this post in threaded view
|

Re: Versioned entry scope usage

dsetrakyan
On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> 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?


>
> What do you think? Do you see any other real life scenarios I'm missing?
>
> --
> Denis
>
Reply | Threaded
Open this post in threaded view
|

Re: Versioned entry scope usage

Denis Magda


On 7/30/2015 4:36 PM, Dmitriy Setrakyan wrote:

> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> 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?
>
Dmitriy, to support it at the level of Cache.iterator() and
IgniteCache.localEntries() requires a lot of modifications in Ignite
code. That's why I'm interested whether it makes sense to do it or not
before start coding.
Can't say how the modifications will affect performance, from the first
view they shouldn't.

--
Denis

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

Reply | Threaded
Open this post in threaded view
|

Re: Versioned entry scope usage

Valentin Kulichenko
In reply to this post by dsetrakyan
On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> 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.


>
> >
> > What do you think? Do you see any other real life scenarios I'm missing?
> >
> > --
> > Denis
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Versioned entry scope usage

Denis Magda


On 7/30/2015 10:16 PM, Valentin Kulichenko wrote:

> On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
>> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> 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?

--
Denis

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

Reply | Threaded
Open this post in threaded view
|

Re: Versioned entry scope usage

dsetrakyan
On Thu, Jul 30, 2015 at 11:56 PM, Denis Magda <[hidden email]> wrote:

>
>
> On 7/30/2015 10:16 PM, Valentin Kulichenko wrote:
>
>> On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[hidden email]
>> >
>> wrote:
>>
>> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> 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
>>>>
>>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Versioned entry scope usage

Denis Magda


On 7/31/2015 10:26 AM, Dmitriy Setrakyan wrote:

> On Thu, Jul 30, 2015 at 11:56 PM, Denis Magda <[hidden email]> wrote:
>
>>
>> On 7/30/2015 10:16 PM, Valentin Kulichenko wrote:
>>
>>> On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[hidden email]
>>> wrote:
>>>
>>> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[hidden email]> 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.
IgniteCache.localEntries() support is in progress. I've almost fully
supported it, there are some non trivial issues left with OFF_HEAP scenario.

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