Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On Jun 13, 2013, at 2:40 PM, Dan Berindei dan.berin...@gmail.com wrote: On Wed, Jun 12, 2013 at 3:39 PM, Mircea Markus mmar...@redhat.com wrote: On 12 Jun 2013, at 13:14, Galder Zamarreño gal...@redhat.com wrote: On Jun 10, 2013, at 12:01 PM, Adrian Nistor anis...@redhat.com wrote: 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). I wonder if anyone noticed my reply earlier... The flag business does need a big re-think. Not only to separate internal from external flags (we have a jira for that [1]), but also to have a way to define which flags can be passed to a particular operation, in a way that's type-safe, and without resulting in a runtime error of the likes of X flag cannot be used with Y operation. IOW, any error on which flag can be used with what operation should ideally be caught at compilation time. I don't have specific ideas on this right now, but I think it'd be good to achieve this. IOW, I suggest we leave it as it is. We need to re-think it anyway. So let's tackle it in 6.0 so that a get operation can never be passed IGNORE_RETURN_VALUES flag, and this being something that's caught at **compilation time**. this would be the elegant way of doing it. An even more elegant solution would be to make put return void by default, and force the user to state explicitly that he wants a return value - a la JSR-107. I know that would break backwards compatibility, so it may not be an option even in 6.0, but still I think we should focus on that. Maybe it's worth making other flags type-safe, but I don't think it's worth doing it for IGNORE_RETURN_VALUES. Fair point. I hope once JCache (JSR-107) is final we can move towards making their Cache API the main entrance point and reduce our Cache to having only those methods not present in JCache. I'm just about to add another internal flag to Flag as a result of the JCache 0.7 upgrade…, so need to tackle ISPN-2201 to avoid causing more confusion, and alongside avoid the issues that have been highlighted WRT which operations are allowed which flags. I'm happy to do this for 6.0. [1] https://issues.jboss.org/browse/ISPN-2201 I've update the JIRA to track the fact that IGNORE_RETURN_VALUES + get should not be possible. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On Wed, Jun 12, 2013 at 3:39 PM, Mircea Markus mmar...@redhat.com wrote: On 12 Jun 2013, at 13:14, Galder Zamarreño gal...@redhat.com wrote: On Jun 10, 2013, at 12:01 PM, Adrian Nistor anis...@redhat.com wrote: 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). I wonder if anyone noticed my reply earlier... The flag business does need a big re-think. Not only to separate internal from external flags (we have a jira for that [1]), but also to have a way to define which flags can be passed to a particular operation, in a way that's type-safe, and without resulting in a runtime error of the likes of X flag cannot be used with Y operation. IOW, any error on which flag can be used with what operation should ideally be caught at compilation time. I don't have specific ideas on this right now, but I think it'd be good to achieve this. IOW, I suggest we leave it as it is. We need to re-think it anyway. So let's tackle it in 6.0 so that a get operation can never be passed IGNORE_RETURN_VALUES flag, and this being something that's caught at **compilation time**. this would be the elegant way of doing it. An even more elegant solution would be to make put return void by default, and force the user to state explicitly that he wants a return value - a la JSR-107. I know that would break backwards compatibility, so it may not be an option even in 6.0, but still I think we should focus on that. Maybe it's worth making other flags type-safe, but I don't think it's worth doing it for IGNORE_RETURN_VALUES. I'm just about to add another internal flag to Flag as a result of the JCache 0.7 upgrade…, so need to tackle ISPN-2201 to avoid causing more confusion, and alongside avoid the issues that have been highlighted WRT which operations are allowed which flags. I'm happy to do this for 6.0. [1] https://issues.jboss.org/browse/ISPN-2201 I've update the JIRA to track the fact that IGNORE_RETURN_VALUES + get should not be possible. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On Jun 10, 2013, at 12:01 PM, Adrian Nistor anis...@redhat.com wrote: 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). I wonder if anyone noticed my reply earlier... The flag business does need a big re-think. Not only to separate internal from external flags (we have a jira for that [1]), but also to have a way to define which flags can be passed to a particular operation, in a way that's type-safe, and without resulting in a runtime error of the likes of X flag cannot be used with Y operation. IOW, any error on which flag can be used with what operation should ideally be caught at compilation time. I don't have specific ideas on this right now, but I think it'd be good to achieve this. IOW, I suggest we leave it as it is. We need to re-think it anyway. So let's tackle it in 6.0 so that a get operation can never be passed IGNORE_RETURN_VALUES flag, and this being something that's caught at **compilation time**. I'm just about to add another internal flag to Flag as a result of the JCache 0.7 upgrade…, so need to tackle ISPN-2201 to avoid causing more confusion, and alongside avoid the issues that have been highlighted WRT which operations are allowed which flags. I'm happy to do this for 6.0. [1] https://issues.jboss.org/browse/ISPN-2201 On 06/10/2013 12:33 PM, Dan Berindei wrote: On Thu, Jun 6, 2013 at 9:08 PM, Ray Tsang saturn...@gmail.com wrote: On Jun 6, 2013, at 13:26, Mircea Markus mmar...@redhat.com wrote: On 4 Jun 2013, at 13:55, Dan Berindei dan.berin...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On 10 Jun 2013, at 11:01, Adrian Nistor anis...@redhat.com wrote: 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). +1 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On 10 Jun 2013, at 10:33, Dan Berindei dan.berin...@gmail.com wrote: On Thu, Jun 6, 2013 at 9:08 PM, Ray Tsang saturn...@gmail.com wrote: On Jun 6, 2013, at 13:26, Mircea Markus mmar...@redhat.com wrote: On 4 Jun 2013, at 13:55, Dan Berindei dan.berin...@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? It does and it will return null as for PutIfAbsent the IGNORE_RETURN_VALUES flag is honoured. ISPN-3141 affects conditional remove and replace, both returning a *boolean* value, as in this case the cost of not returning the value(null) is the same with the cost of returning the correct value(boolean). 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 what about not even throw and exception but (as you suggested previously) ignore the flag itself. That would allow the valid use case you've mentioned to work nicely. and (optionally) put() operations always return null. Should I create an issue in JIRA for that? +1 Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On Thu, Jun 6, 2013 at 9:08 PM, Ray Tsang saturn...@gmail.com wrote: On Jun 6, 2013, at 13:26, Mircea Markus mmar...@redhat.com wrote: On 4 Jun 2013, at 13:55, Dan Berindei dan.berin...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
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 saturn...@gmail.com mailto:saturn...@gmail.com wrote: On Jun 6, 2013, at 13:26, Mircea Markus mmar...@redhat.com mailto:mmar...@redhat.com wrote: On 4 Jun 2013, at 13:55, Dan Berindei dan.berin...@gmail.com mailto:dan.berin...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On Jun 4, 2013, at 2:55 PM, Dan Berindei dan.berin...@gmail.com wrote: On Tue, Jun 4, 2013 at 12:27 PM, Mircea Markus mmar...@redhat.com wrote: On 3 Jun 2013, at 19:01, Dan Berindei dan.berin...@gmail.com wrote: Fair point... ok, let's leave it as it is now. On Mon, Jun 3, 2013 at 5:23 PM, Galder Zamarreño gal...@redhat.com wrote: On Jun 3, 2013, at 11:52 AM, Dan Berindei dan.berin...@gmail.com wrote: Hi guys 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 :) The flag business does need a big re-think. Not only to separate internal from external flags (we have a jira for that), but also to have a way to define which flags can be passed to a particular operation, in a way that's type-safe, and without resulting in a runtime error of the likes of X flag cannot be used with Y operation. IOW, any error on which flag can be used with what operation should ideally be caught at compilation time. I don't have specific ideas on this right now, but I think it'd be good to achieve this. Cheers, ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On 4 Jun 2013, at 13:55, Dan Berindei dan.berin...@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? Still I think Get + IGNORE_RETURN_VALUES doesn't make any sense :-) Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On Jun 6, 2013, at 13:26, Mircea Markus mmar...@redhat.com wrote: On 4 Jun 2013, at 13:55, Dan Berindei dan.berin...@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? Still I think Get + IGNORE_RETURN_VALUES doesn't make any sense :-) +1. It definitely threw me off... Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On 3 Jun 2013, at 19:01, Dan Berindei dan.berin...@gmail.com wrote: Fair point... ok, let's leave it as it is now. On Mon, Jun 3, 2013 at 5:23 PM, Galder Zamarreño gal...@redhat.com wrote: On Jun 3, 2013, at 11:52 AM, Dan Berindei dan.berin...@gmail.com wrote: Hi guys 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 :-) Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On Tue, Jun 4, 2013 at 12:27 PM, Mircea Markus mmar...@redhat.com wrote: On 3 Jun 2013, at 19:01, Dan Berindei dan.berin...@gmail.com wrote: Fair point... ok, let's leave it as it is now. On Mon, Jun 3, 2013 at 5:23 PM, Galder Zamarreño gal...@redhat.com wrote: On Jun 3, 2013, at 11:52 AM, Dan Berindei dan.berin...@gmail.com wrote: Hi guys 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 :) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
Hi Dan, I'm not sure I understood this. How can I prevent it to return values if you have the flag ignored? Note that in some cases it makes a huge performance difference. Sanne On 3 June 2013 10:52, Dan Berindei dan.berin...@gmail.com wrote: Hi guys 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? Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
Sanne, I'm only talking about get operations. I was thinking that if you call cache.get(key), you want the value of that key, regardless of where it is stored... Obviously, write operations would still behave as they do now. On Mon, Jun 3, 2013 at 12:59 PM, Sanne Grinovero sa...@infinispan.orgwrote: Hi Dan, I'm not sure I understood this. How can I prevent it to return values if you have the flag ignored? Note that in some cases it makes a huge performance difference. Sanne On 3 June 2013 10:52, Dan Berindei dan.berin...@gmail.com wrote: Hi guys 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? Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
I agree, eventually we should have separate getAndXxx methods like JSR-107. The Jokre is cool, but running with an instrumentation agent is never going to be ok for everyone. I was thinking about this in the context of AtomicHashMap. It uses withFlags(SKIP_REMOTE_LOOKUP, DELTA_WRITE, FORCE_WRITE_LOCK) for write operations, but it still has to keep a reference to the original cache for read operations. Of course, after more digging, I don't think the SKIP_REMOTE_LOOKUP flag is that useful for writes either (since we already have a copy of the map in the invocation context at that point). But it seemed like an interesting idea in the general case. On Mon, Jun 3, 2013 at 1:15 PM, Sanne Grinovero sa...@infinispan.orgwrote: ha got it, good point. but I'm not persuaded: doesn't it get even more confusing for users? Imho it would be more helpful to throw an exception. these flags are confusing and ideally we should evolve the API, as the JSR did, or push on The Jokre. On 3 Jun 2013 11:08, Dan Berindei dan.berin...@gmail.com wrote: Sanne, I'm only talking about get operations. I was thinking that if you call cache.get(key), you want the value of that key, regardless of where it is stored... Obviously, write operations would still behave as they do now. On Mon, Jun 3, 2013 at 12:59 PM, Sanne Grinovero sa...@infinispan.orgwrote: Hi Dan, I'm not sure I understood this. How can I prevent it to return values if you have the flag ignored? Note that in some cases it makes a huge performance difference. Sanne On 3 June 2013 10:52, Dan Berindei dan.berin...@gmail.com wrote: Hi guys 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? Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
On Jun 3, 2013, at 11:52 AM, Dan Berindei dan.berin...@gmail.com wrote: Hi guys 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? Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Retrieval operations with the IGNORE_RETURN_VALUES flag
Fair point... ok, let's leave it as it is now. On Mon, Jun 3, 2013 at 5:23 PM, Galder Zamarreño gal...@redhat.com wrote: On Jun 3, 2013, at 11:52 AM, Dan Berindei dan.berin...@gmail.com wrote: Hi guys 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? Cheers Dan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
