On May 16, 2011, at 7:47 PM, Sanne Grinovero wrote: > 2011/5/16 Emmanuel Bernard <emman...@hibernate.org>: >> Couldn't you have a higher level flag that says Flag.IGNORE_RETURN_VALUE so >> that people wo a PhD can benefit form the feature? > > when I discovered that, that was my exact thought as well. > > then we started discussing about a proper interface to avoid return > values.. should be typesafe (i.e. not have a return type at all), but > then there are two main use cases: no return values, async return > values. and the complexity of the API exploded, the thread was killed > and we got a better idea. I hope we'll publish that soon.
Publish what? > > Sanne > >> >> On 16 mai 2011, at 19:37, Sanne Grinovero wrote: >> >>> good place to remind that if you don't want the return value of a >>> write operation then you need to specify both flags: >>> cache.withFlags(Flag.SKIP_REMOTE_LOOKUP, Flag.SKIP_CACHE_LOAD).put( .. ) >>> >>> I guess that nobody knows that :) >>> >>> Sanne >>> >>> 2011/5/16 Emmanuel Bernard <emman...@hibernate.org>: >>>> Yes I think something use case driven would make a nice portal. >>>> >>>> On 16 mai 2011, at 17:22, Galder Zamarreño wrote: >>>> >>>>> >>>>> On May 16, 2011, at 2:23 PM, Emmanuel Bernard wrote: >>>>> >>>>>> Your description explains a use case / pattern but wo code showing how >>>>>> to implement it properly. >>>>> >>>>> True and I think you have a point, though the use of putForExternalRead() >>>>> itself is something that should be documented either its javadoc or a >>>>> separate wiki. >>>>> >>>>> This wiki should be limited to explaining the actual flags. >>>>> >>>>>> In this case what's the best way for me to verify that the new data has >>>>>> indeed been pushed to the cache? >>>>>> put and then immediate get >>>>>> Put, wait, get >>>>>> Put all entries, then get all entries, and loop till all entries >>>>>> supposedly put are indeed present. >>>>>> Same as above but with some kind of batch size instead of all the data >>>>>> set? >>>>>> Or is there some kind of queue/log I can look for to get the reliable >>>>>> list of failures? >>>>> >>>>> If you need immediate verification I would not use putForExternalRead() >>>>> but maybe a putAsync() with the flags you want which returns you a future >>>>> and allows you to verify the result in a less wacky way. >>>>> >>>>> The normal use case of PFER is: >>>>> 1. Check the cache whether an k/v is present >>>>> 2. If not present, go to db and call PFER with it. >>>>> 3. Use whatever you retrieved from db to do your job. >>>>> ... >>>>> N. Check the cache whether k/v is present >>>>> N+1. Oh, it's present, so just use it instead of going to DB. >>>>> >>>>> This could be a good FAQ, wdyt? >>>>> >>>>>> >>>>>> Emmanuel >>>>>> >>>>>> >>>>>> On 16 mai 2011, at 10:20, Galder Zamarreño <gal...@redhat.com> wrote: >>>>>> >>>>>>> More wikis. I've just created http://community.jboss.org/docs/DOC-16803 >>>>>>> which explains what Infinispan flags are, what they're used for...etc. >>>>>>> >>>>>>> Feedback appreciated >>>>>>> -- >>>>>>> Galder Zamarreño >>>>>>> Sr. Software Engineer >>>>>>> Infinispan, JBoss Cache >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>>> -- >>>>> Galder Zamarreño >>>>> Sr. Software Engineer >>>>> Infinispan, JBoss Cache >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev