Re: Versioned entry scope usage
On 7/31/2015 10:26 AM, Dmitriy Setrakyan wrote: On Thu, Jul 30, 2015 at 11:56 PM, Denis Magda wrote: On 7/30/2015 10:16 PM, Valentin Kulichenko wrote: On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan 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
Re: Versioned entry scope usage
On Thu, Jul 30, 2015 at 11:56 PM, Denis Magda wrote: > > > On 7/30/2015 10:16 PM, Valentin Kulichenko wrote: > >> On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan > > >> wrote: >> >> On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda 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 >
Re: Versioned entry scope usage
On 7/30/2015 10:16 PM, Valentin Kulichenko wrote: On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan wrote: On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda 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
Re: Versioned entry scope usage
On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan wrote: > On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda 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 > > >
Re: Versioned entry scope usage
On 7/30/2015 4:36 PM, Dmitriy Setrakyan wrote: On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda 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
Re: Versioned entry scope usage
On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda 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 >
