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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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 <galder(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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 <emmanuel(a)hibernate.org&gt;: > 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 <galder(a)redhat.com&gt; 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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

2011/5/16 Emmanuel Bernard <emmanuel(a)hibernate.org&gt;: > 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.

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 <emmanuel(a)hibernate.org&gt;: >>> 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 <galder(a)redhat.com&gt; 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(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>> >>>>> _______________________________________________ >>>>> infinispan-dev mailing list >>>>> infinispan-dev(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

+1! On 16 May 2011, at 18: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 <emmanuel(a)hibernate.org&gt;: >> 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 <galder(a)redhat.com&gt; 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev