Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <SNT147-W366956301196E1E04762BCF000@phx.gbl>
References: <SNT147-W21C0E54AA65621321C8BB8CF050@phx.gbl>
	<CA+NutANgxShAiYMReHRCh-NO7KeyHVA_rm=UC6J-cSxanDnAZw@mail.gmail.com>
	<SNT147-W366956301196E1E04762BCF000@phx.gbl>
Date: Mon, 30 Nov 2015 13:11:13 +0300
Message-ID: 
 <CABDss3i=ZBPg=n3Vhhb4n1Qddt21MasVR-qtitqef_zhZRaz_w@mail.gmail.com>
Subject: Re: EntryProcessor execution semantics
From: Alexey Goncharuk <alexey.goncharuk@gmail.com>
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=94eb2c032720cc42b80525bf42f1

--94eb2c032720cc42b80525bf42f1
Content-Type: text/plain; charset=UTF-8

Andrey,

If I leave behind my knowledge about Ignite internals, my expectation would
be that an EntryProcessor is invoked on all affinity - both primary and
backup - nodes in the grid. The main reason behind this expectation is that
usually a serialized EntryProcessor instance is smaller than resulting
object being stored in the cache, so sending a serialized EntryProcessor
should be cheaper. Is there a specific reason you expect an EntryProcessor
to be called only once across all the nodes?

I would not imply any restrictions on how many times an EntryProcessor is
called during a cache update. For example, in a case of explicit optimistic
READ_COMMITTED transaction it may be called more than once because Ignite
needs to calculate a return value for the first invoke() and then it should
be called second time during commit when transactional locks are held.

Current requirement is that an EntryProcessor should be a stateless
function, and it may be called more than once (but of course it will
receive the same cache value every time). I agree that this should be
properly articulated in the documentation, I will make sure that it will be
reflected in the forthcoming 1.5 release javadocs.

--94eb2c032720cc42b80525bf42f1--