RE: EntryProcessor in ATOMIC cache and CLOCK versioning mode

2016-02-09 Thread Alexey Goncharuk
Igniters,

I want to bring community attention to the ticket [1] once again since it
raises a lot of confusion among Ignite users [2] and I would like this to
be addressed in 1.6.

The alternatives for the case when entry processor is used in CLOCK mode
are:
 * Print a warning, but still allow to use invoke() since it will work if
key access is synchronized by external means.
 * Throw an exception and force users to switch to PRIMARY mode when
invoke() is used.

Any thoughts / other suggestions?

-- AG

[1] https://issues.apache.org/jira/browse/IGNITE-2088
[2]
http://apache-ignite-users.70518.x6.nabble.com/Version-issue-with-concurrent-cache-updates-EntryProcessor-td2896.html


Re: EntryProcessor in ATOMIC cache and CLOCK versioning mode

2016-02-09 Thread Alexey Goncharuk
After a second thought, I think the warning should be printed anyways when
CLOCK versioning mode is used because it does not guarantee happens-before
relationship when cache operations are invoked on different nodes (see an
example in pseudo-code below). Essentially, when cache operations are
invoked on different nodes within a time span smaller or equal than time
sync error, they are considered to be run concurrently.

IgniteCache cache = ignite.cache("name");

cache.put(1, 1);

// Select a random remote node.
ClusterGroup grp = ignite.cluster().forRemotes().forRandom();

ignite.compute(grp).call(new Callable() {
public Object call() throws Exception {
cache.put(1, 2); // This does not guarantee to succeed in CLOCK
mode.
}
});

// This may fail in CLOCK mode.
assert cache.get(1) == 2;

I agree that the documentation must be updated accordingly, and I think the
warning printed should contain a link to the page.

Any other thoughts?


Re: EntryProcessor in ATOMIC cache and CLOCK versioning mode

2016-02-09 Thread Dmitriy Setrakyan
I don’t think there is anything else that can be done in addition to
printing our a warning and fixing documentation. Looks like an easy fix, I
marked it with “newbie”, so some of the new community members could pick it
up.

On Tue, Feb 9, 2016 at 5:17 AM, Alexey Goncharuk  wrote:

> After a second thought, I think the warning should be printed anyways when
> CLOCK versioning mode is used because it does not guarantee happens-before
> relationship when cache operations are invoked on different nodes (see an
> example in pseudo-code below). Essentially, when cache operations are
> invoked on different nodes within a time span smaller or equal than time
> sync error, they are considered to be run concurrently.
>
> IgniteCache cache = ignite.cache("name");
>
> cache.put(1, 1);
>
> // Select a random remote node.
> ClusterGroup grp = ignite.cluster().forRemotes().forRandom();
>
> ignite.compute(grp).call(new Callable() {
> public Object call() throws Exception {
> cache.put(1, 2); // This does not guarantee to succeed in CLOCK
> mode.
> }
> });
>
> // This may fail in CLOCK mode.
> assert cache.get(1) == 2;
>
> I agree that the documentation must be updated accordingly, and I think the
> warning printed should contain a link to the page.
>
> Any other thoughts?
>