ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: EntryProcessor execution semantics
Date Tue, 01 Dec 2015 18:48:38 GMT
On Tue, Dec 1, 2015 at 8:34 AM, Andrey Kornev <andrewkornev@hotmail.com>
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: dsetrakyan@apache.org
> > Date: Mon, 30 Nov 2015 23:16:58 -0800
> > Subject: Re: EntryProcessor execution semantics
> > To: dev@ignite.apache.org
> >
> > On Mon, Nov 30, 2015 at 9:02 AM, Andrey Kornev <andrewkornev@hotmail.com
> >
> > 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?
>
>

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