On Tue, Dec 1, 2015 at 8:34 AM, Andrey Kornev <[email protected]> wrote:
> Dmitriy, > > Here, by "stateless" I meant whatever Alexey meant in his previous post in > this thread. But I'm really talking about being able to have EPs with side > effects and therefore the execution semantics should be "exactly-once" by > default. Besides, maybe it's just me, but intuitively the expectation of > Cache.invoke() is that the EP will be executed only once because > *logically* there can only be one entry with the given key in the cache to > which the EP is applied. Having the EP executed many times for the same > entry comes as a big surprise, at least to me. > > Maybe it's worth considering an API similar to what Hazelcast has to make > it possible to explicitly control EP's execution semantics. > Andrey, can you create a ticket and propose a design? We could continue this discussion there. > > Regards > Andrey > > > From: [email protected] > > Date: Mon, 30 Nov 2015 23:16:58 -0800 > > Subject: Re: EntryProcessor execution semantics > > To: [email protected] > > > > On Mon, Nov 30, 2015 at 9:02 AM, Andrey Kornev <[email protected] > > > > wrote: > > > > > > > > Neither Coherence nor Hazelcast require the EP to be stateless and > > > side-effect free. Even better Hazelcast makes the choice explicit by > > > providing the backup aware processor API and it's then up to the user > to > > > ensure statelessness etc. But Ignite is just too clever. > > > > > > > Andrey, stateful EP seems a bit utopian to me, since the state would not > > survive between executions anyway. Can you elaborate? > >
