[infinispan-dev] Per-invocation flag wiki

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Per-invocation flag wiki

Galder Zamarreno
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Emmanuel Bernard
Your description explains a use case / pattern but wo code showing how to implement it properly.

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?

Emmanuel


On 16 mai 2011, at 10:20, Galder Zamarreño <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Galder Zamarreno

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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Emmanuel Bernard
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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Sanne Grinovero
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 <[hidden email]>:

> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Emmanuel Bernard
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?

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 <[hidden email]>:
>> 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 <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Sanne Grinovero
2011/5/16 Emmanuel Bernard <[hidden email]>:
> 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 <[hidden email]>:
>>> 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 <[hidden email]> 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
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Galder Zamarreno
In reply to this post by Emmanuel Bernard
Fair point, I'll add an FAQ or Wiki on this.

On May 16, 2011, at 5:24 PM, Emmanuel Bernard wrote:

> 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 <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Galder Zamarreno
In reply to this post by Sanne Grinovero

On May 16, 2011, at 7:47 PM, Sanne Grinovero wrote:

> 2011/5/16 Emmanuel Bernard <[hidden email]>:
>> 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 <[hidden email]>:
>>>> 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 <[hidden email]> 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
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> infinispan-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> --
>>>>> Galder Zamarreño
>>>>> Sr. Software Engineer
>>>>> Infinispan, JBoss Cache
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Manik Surtani
In reply to this post by Sanne Grinovero
+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 <[hidden email]>:
>> 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 <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
[hidden email]
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org




_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Per-invocation flag wiki

Galder Zamarreno
That's been added to http://community.jboss.org/docs/DOC-16803

On May 17, 2011, at 7:38 PM, Manik Surtani wrote:

> +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 <[hidden email]>:
>>> 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 <[hidden email]> 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
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> [hidden email]
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev