RE: EntryProcessor in ATOMIC cache and CLOCK versioning mode
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
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
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 Goncharukwrote: > 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? >