[ 
https://issues.apache.org/jira/browse/IGNITE-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680788#comment-14680788
 ] 

Alexey Goncharuk edited comment on IGNITE-946 at 8/10/15 9:27 PM:
------------------------------------------------------------------

In general, I do not like the current {{VersionedEntryEx}} interface. I think 
it should have only one method {{IgniteVersion version()}}, and 
{{IgniteVersion}} should have only {{updateTime}}. Other methods, such as 
{{topologyVersion}} or let alone {{order}} are meaningless for a user. 
Moreover, it is hard to implement the most straightforward use-case - check 
whether the version of a cache entry has changed in between the user calls. In 
order to do this one has to compare the results of all four methods.

{code}
public interface IgniteVersion {
    long updateTime();
}

public interface VersionedEntry extends Cache.Entry {
    IgniteVersion version();
}
{code}
 
The way I see it should work is represented in a snippet below:
{code}
IgniteVersion ver1 = entry.version();

// Optimistically assume that no updates will happen and do some business-logic 
based on entry value.
...

refreshedEntry = getEntry(key);

IgniteVersion ver2 = refreshedEntry.version()

if (!ver1.equals(ver2)) {
    // Entry has been concurrently updated.
}
{code}

Needless to say that an instance of versioned entry has to be immutable, so 
that {{value()}} method will always be reflected by a correct {{version()}}.


was (Author: agoncharuk):
In general, I do not like the current {{VersionedEntryEx}} interface. I think 
it should have only one method {{IgniteVersion version()}}, and 
{{IgniteVersion}} should have only {{updateTime}}. Other methods, such as 
{{topologyVersion}} or let alone {{order}} are meaningless for a user. 
Moreover, it is hard to implement the most straightforward use-case - check 
whether the version of a cache entry has changed in between the user calls. In 
order to do this one has to compare the results of all four methods.
 
The way I see it should work is represented in a snippet below:
{code}
IgniteVersion ver1 = entry.version();

// Optimistically assume that no updates will happen and do some business-logic 
based on entry value.
...

refreshedEntry = getEntry(key);

IgniteVersion ver2 = refreshedEntry.version()

if (!ver1.equals(ver2)) {
    // Entry has been concurrently updated.
}
{code}

Needless to say that an instance of versioned entry has to be immutable, so 
that {{value()}} method will always be reflected by a correct {{version()}}.

> Need to expose versioned cache entry to public API
> --------------------------------------------------
>
>                 Key: IGNITE-946
>                 URL: https://issues.apache.org/jira/browse/IGNITE-946
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>    Affects Versions: sprint-4
>            Reporter: Valentin Kulichenko
>            Assignee: Denis Magda
>            Priority: Critical
>              Labels: Usability
>             Fix For: ignite-1.4
>
>         Attachments: ignite-946-2.patch, ignite-946-3.patch, ignite-946.patch
>
>
> Currently we have versioned entry, but it's not available on public API, but 
> knowing version can be useful in some cases. Need to make it accessible via 
> {{unwrap}} method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to