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 <sanne@infinispan.org> wrote:

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.berindei@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 <sanne@infinispan.org> wrote:
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.berindei@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