Interface AsyncCache<K,​V>

  • All Known Subinterfaces:
    BasicCache<K,​V>, RemoteCache<K,​V>

    public interface AsyncCache<K,​V>
    AsyncCache. This interface is implemented by caches which support asynchronous variants of the various put/get/remove/clear/replace/putAll methods Note that these methods only really make sense if you are using a clustered cache. I.e., when used in LOCAL mode, these "async" operations offer no benefit whatsoever. These methods, such as putAsync(Object, Object) offer the best of both worlds between a fully synchronous and a fully asynchronous cache in that a CompletableFuture is returned. The CompletableFuture can then be ignored or thrown away for typical asynchronous behaviour, or queried for synchronous behaviour, which would block until any remote calls complete. Note that all remote calls are, as far as the transport is concerned, synchronous. This allows you the guarantees that remote calls succeed, while not blocking your application thread unnecessarily. For example, usage such as the following could benefit from the async operations:
       CompletableFuture f1 = cache.putAsync("key1", "value1");
       CompletableFuture f2 = cache.putAsync("key2", "value2");
       CompletableFuture f3 = cache.putAsync("key3", "value3");
       f1.get();
       f2.get();
       f3.get();
     
    The net result is behavior similar to synchronous RPC calls in that at the end, you have guarantees that all calls completed successfully, but you have the added benefit that the three calls could happen in parallel. This is especially advantageous if the cache uses distribution and the three keys map to different cache instances in the cluster.

    Also, the use of async operations when within a transaction return your local value only, as expected. A CompletableFuture is still returned though for API consistency. These methods can have benefit over their sync versions even in LOCAL mode.

    Since:
    6.0
    Author:
    Mircea Markus, Manik Surtani, Galder ZamarreƱo, Tristan Tarrant