[infinispan-dev] Why is loading from store needed before storing in cache store?

[Manik Surtani]

On 11 Nov 2010, at 08:13, Elias Ross wrote:

> On Thu, Oct 21, 2010 at 1:42 AM, "이희승 (Trustin Lee)" <trustin at 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.  :-)