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>:
>> 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>
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