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(a)gmail.com
<mailto:saturnism@gmail.com>> wrote:
On Jun 6, 2013, at 13:26, Mircea Markus <mmarkus(a)redhat.com
<mailto:mmarkus@redhat.com>> wrote:
>
> On 4 Jun 2013, at 13:55, Dan Berindei <dan.berindei(a)gmail.com
<mailto:dan.berindei@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev