[infinispan-dev] Optional in listener events

William Burns mudokonman at gmail.com
Mon Aug 22 14:15:29 EDT 2016


I like the idea of having a variable to set on the listener annotation.
This way we can know for sure if we need to force previous values for some
listeners and not for others.

It seems the default should be to force the previous value to be more
inline with the current behavior, but I fear no one will use the opposite
in this case though.  What do you guys think?

On Mon, Aug 22, 2016 at 4:31 AM Adrian Nistor <anistor at redhat.com> wrote:

> Hi Radim,
>
> Continuous query is built on top of these listeners. CQ _always_ needs
> the previous value and it is very convenient in this case that the
> command is forced to load the previous value. I imagine there may be
> other use cases where we cannot live without the prev value.
>
> I think the listener should be able to state if it needs the prev value
> at registration time. Maybe add a new attribute in the Listener
> annotation? Similar to how we handled Observation.
>
> Adrian
>
> On 08/19/2016 11:34 PM, Radim Vansa wrote:
> > Hi,
> >
> > as I am trying to simplify current entry wrapping and distribution code,
> > I often find that listeners can get wrong previous value in the event,
> > and it sometimes forces the command to load the value even if it is not
> > needed for the command.
> >
> > I am wondering if we should change the previous value in events to
> > Optional - we can usually at least detect that we cannot provide a
> > reliable value (e.g. after retry due to topology change, or because the
> > command did not bothered to load the previous value from cache loader)
> > and return empty Optional.
> >
> > WDYT?
> >
> > Radim
> >
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160822/f2ddb319/attachment.html 


More information about the infinispan-dev mailing list