Re: [infinispan-dev] Why is loading from store needed before storing in cache store?
On 11 Nov 2010, at 08:13, Elias Ross wrote:
On Thu, Oct 21, 2010 at 1:42 AM, "이희승 (Trustin Lee)"
<trustin(a)gmail.com> wrote:
>
> I love the idea of returning NoReturnCache instead of returning Cache
> with unexpected behavior. Perhaps we could even extract the async
> operations and do the same:
>
> AsyncCache ac = cache.asAsync();
> NotifyingFuture<..> f = ac.put(k, v);
>
> But, what if a user want the combination of NoReturnCache and AsyncCache?
>
> Name? We should brainstorm a little bit more. :-)
It's very nice to be able to use the pure java.util.Map interface in
code that really only makes use of get/put/remove--while allowing at
least for the "NoReturnCache" behavior. Client code shouldn't be tied
to a specific Infinispan interface, though I do agree that such an
interface will help users avoid trouble.
What may be useful is to simply return an interface that is restricted
to the altered methods, and a method to get the parent cache, and a
method to get a java.util.Map view.
For example:
interface Cache {
NoReturnCache noReturn();
AsyncCache async();
}
interface NoReturnCache {
void put(K k, V v);
void remove(K k);
Cache getCache();
NoReturnCache async(); // is get() async?
Map map();
}
interface AsyncCache {
NotifyingFuture put(K k, V v);
// etc.
Cache getCache();
Map map(); // necessary
}
Yeah but then you end up in a situation where you'd have to do stuff like:
nrCache.put(k, v);
nrCache.map().get(k);
nrCache.map().contains(k);
// etc
This is why we went for Cache extends Map in the first place to give you a clean API. Now
it just so happens that suppressing return vals is a valid optimisation. :-)