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.