ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: EntryProcessor execution semantics
Date Mon, 30 Nov 2015 10:11:13 GMT

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message