[infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag

[Adrian Nistor]

Maybe we could just clarify the javadoc of IGNORE_RETURN_VALUES and say 
that it only applies to write operations and is ignored for everything 
else? Why punish the user with an exception when doing a 'get'?

We already document there's a (very common-sense) exception for 
conditional writes were the flag is ignored (ISPN-3141).

On 06/10/2013 12:33 PM, Dan Berindei wrote:
>
>
>
> On Thu, Jun 6, 2013 at 9:08 PM, Ray Tsang <saturnism at gmail.com 
> <mailto:saturnism at gmail.com>> wrote:
>
>     On Jun 6, 2013, at 13:26, Mircea Markus <mmarkus at redhat.com
>     <mailto:mmarkus at redhat.com>> wrote:
>
>     >
>     > On 4 Jun 2013, at 13:55, Dan Berindei <dan.berindei at gmail.com
>     <mailto:dan.berindei at gmail.com>> wrote:
>     >
>     >>>> CacheLoaderInterceptor and DistributionInterceptor both
>     honour the IGNORE_RETURN_VALUES flag for get commands, but I think
>     it would be more useful if they ignored it - just like they ignore
>     it for conditional commands.
>     >>>>
>     >>>> That would make it possible for users to only keep a
>     reference to a
>     cache.getAdvancedCache().withFlags(IGNORE_RETURN_VALUES) and use
>     it for both read and write operations.
>     >>>>
>     >>>> What do you think?
>     >>>
>     >>> If I was to take the role of a colleague of the person who's
>     written the Infinispan code, it'd be very confused to see a cache
>     reference created with IGNORE_RETURN_VALUES being used for a get()
>     operation... I can see myself thinking: "Why on earth do you call
>     get with IGNORE_RETURN_VALUES?"
>     >>
>     >> Isn't Galder's point not to allow invoking get with
>     IGNORE_RETURN_VALUES? As both of you pointed out, Get +
>     IGNORE_RETURN_VALUES doesn't make any sense :-)
>     >>
>     >>
>     >> You'd think conditional operations with IGNORE_RETURN_VALUES
>     don't make sense either, yet we have a special case to handle
>     those as if the flag wasn't present :)
>     >
>     > I guess you're referring to ISPN-3141?
>
>
> Exactly. Does it make sense to call 
> cache.withFlags(IGNORE_RETURN_VALUES).putIfAbsent(k, v)? What should 
> it return?
>
>     > Still I think Get + IGNORE_RETURN_VALUES doesn't make any sense :-)
>
>     +1. It definitely threw me off...
>
>
> Ok, maybe IGNORE_RETURN_VALUES wouldn't be the best flag name for what 
> I had in mind... I was thinking of a scenario where the application 
> needs to do both reads and writes, but for writes it never needs to 
> know the previous value. In that scenario it would make sense to call 
> something like
>
>     cache = 
> cacheManager.getCache().getAdvancedCache().withFlags(IGNORE_RETURN_VALUES_ON_WRITES)
>
> at the beginning and only ever use that reference in the application. 
> I agree that using the existing IGNORE_RETURN_VALUES flag for that 
> would be a bit misleading, though.
>
> Should we change anything about the IGNORE_RETURN_VALUES, then? I 
> guess it would be relatively simple to make it so that get() 
> operations with the flag throw an exception and (optionally) put() 
> operations always return null. Should I create an issue in JIRA for that?
>
> Cheers
> Dan
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130610/cb20be83/attachment.html