[
https://issues.jboss.org/browse/ISPN-7224?page=com.atlassian.jira.plugin....
]
Mike Noordermeer edited comment on ISPN-7224 at 4/3/17 11:20 AM:
-----------------------------------------------------------------
It would solve my issue, as we mainly use local (non-replicating/invalidating) caches.
Also, I wouldn't want global locking, so I think any locks should only apply to the
local node when possible. In our case, we are retrieving and parsing a rather large object
from a remote URL, and caching it (incl. passivation). The URL is unique per-user, and
users may perform multiple requests at the same time. In that case, I simply want the
second request to wait a bit for the first to finish, but if the supplier is invoked twice
nothing will break really.
I think a best-effort implementation is all that is needed, and users locking/reusing
caches used by the Spring cache abstraction are asking for trouble. I think an atomicity
guarantee may be too much, especially in replicated scenarios, but that's not a
problem.
was (Author: miken123):
It would solve my issue, as we mainly use local (non-replicating/invalidating) caches.
Also, I wouldn't want global locking, so I think any locks should only apply to the
local node when possible. I our case, we are retrieving and parsing a rather large object
from a remote URL, and caching it (incl. passivation). The URL is unique per-user, and
users may perform multiple requests at the same time. In that case, I simply want the
second request to wait a bit for the first to finish, but if the supplier is invoked twice
nothing will break really.
I think a best-effort implementation is all that is needed, and users locking/reusing
caches used by the Spring cache abstraction are asking for trouble. I think an atomicity
guarantee may be too much, especially in replicated scenarios, but that's not a
problem.
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/37ba79c4a8d35617c5f6a...]
Let me know if I can help.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)