If we can drop the pre-events, it would be possible to skip the loading/wrapping of the previous value. The method DataContainer.put() could return the previous value/metadata that could be used to trigger the post-event.
However, it has a problem that I haven't solved it yet: if the value is not in memory it will not be loaded (cache-stores / rebalance in progress). Would it work for CQ? Cheers, Pedro On 22-08-2016 19:15, William Burns wrote: > 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 <anis...@redhat.com > <mailto:anis...@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@lists.jboss.org <mailto:infinispan-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
