On 7/30/2015 10:16 PM, Valentin Kulichenko wrote:
On Thu, Jul 30, 2015 at 6:36 AM, Dmitriy Setrakyan <[email protected]>
wrote:
On Thu, Jul 30, 2015 at 6:30 AM, Denis Magda <[email protected]> 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
