[infinispan-issues] [JBoss JIRA] (ISPN-7224) Support synchronous get in Spring's cache abstraction

[Sebastian Łaskawiec (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-7224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13387989#comment-13387989 ] 

Sebastian Łaskawiec commented on ISPN-7224:
-------------------------------------------

hmmmm it's not that easy as you think guys... So let me try to explain my concerns a bit more...

The {{Cache}} instance on which SpringCache support is baked can be re-used in many different places. There's nothing that prevents a user from grabbing an instance and locking the entire container for some reason. In that case {{Cache#get(Object, Callable<T>)}} would block forever. The second aspect is asynchronous replication. Imagine you cache is clustered and at the same time you supply object {{A}} on one node and object {{B}} on another one. In that case your clustered code will also invoke the supplier twice.

The only thing we _could_ do is to provide "best effort" to synchronize on the key by locking it (with ability to disable this feature in configuration). This still doesn't give you any guarantees that your supplier won't be invoked twice and for me it's any better than {{computeIfAbsent}}. Would it solve your problem [~miken123]?

> Support synchronous get in Spring's cache abstraction
> -----------------------------------------------------
>
>                 Key: ISPN-7224
>                 URL: https://issues.jboss.org/browse/ISPN-7224
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Spring Integration
>            Reporter: Stéphane Nicoll
>            Assignee: Sebastian Łaskawiec
>            Priority: Critical
>             Fix For: 9.0.0.Beta1, 9.0.0.Final
>
>
> Spring Framework 4.3 has introduced a read-through option See https://jira.spring.io/browse/SPR-9254 for more details. In practice this would require you to compile against 4.3 and implement the additional method. 
> The code is meant to be backward compatible with previous version, as long as you're guarding the new exception in an inner class, see [this implementation for an example|https://github.com/hazelcast/hazelcast/blob/37ba79c4a8d35617c5f6a770eec3705f2852f938/hazelcast-spring/src/main/java/com/hazelcast/spring/cache/HazelcastCache.java#L162-L168]
> Let me know if I can help.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)