anchor.diff:  * <<bucket4j-infinispan, bucket4j-infinispan>>
   * <<bucket4j-coherence, bucket4j-coherence>>
   
  -Also, implementation the asynchronous support for any other JCache provider outside from the list above should be easy exercise, so feel free to return back the pull request addressed to cover your favorite JCache provider.
  -
  -==== Verification of compatibility with particular JCache provider is your responsibility
  -IMPORTANT: Keep in mind that there are many non-certified implementations of JCache specification on the market.
  +Also, implementing the asynchronous support for any other JCache provider outside of the list above should be an easy exercise, so feel free to return back the pull request addressed to cover your favorite JCache provider.
  +
  +==== Verification of compatibility with a particular JCache provider is your responsibility
  +IMPORTANT: Keep in mind that there are many non-certified implementations of JCache specifications on the market.
   Many of them want to increase their popularity by declaring support for the JCache API,
   but often only the API is supported and the semantic of JCache is totally ignored.
  -Usage Bucket4j with this kind of libraries should be completely avoided.
  -
  -Bucket4j is only compatible with implementations which obey the JCache specification rules(especially related to EntryProcessor execution). Oracle Coherence, Apache Ignite, Hazelcast are good examples of safe implementations of JCache.
  +Usage Bucket4j with this kind of library should be completely avoided.
  +
  +Bucket4j is only compatible with implementations that obey the JCache specification rules(especially related to EntryProcessor execution). Oracle Coherence, Apache Ignite, Hazelcast are good examples of safe implementations of JCache.
   
   IMPORTANT: Because it is impossible to test all possible JCache providers, you need to test your provider by yourself.
   
  
positive.code: ----
  
  ==== Example 2 - limiting access to service by contract agreements
  > Imagine that you provide paid language translation service via HTTP. Each user has unique agreement which differs from each other.
  Details of each agreement is stored in relational database, and takes significant time to fetch(for example 100ms). 
  The example above will not work fine in this case, because time to create/fetch configuration of bucket from database
  will be 100 times slower than limit-checking itself.
  Bucket4j solves this problem via lazy configuration suppliers which are called if and only if bucket was not yet stored in grid,
  thus it is possible to implement solution  that will read agreement from database once per each user.
  
  [source, java]
  ----
  
negative.code:     // service to provide per user limits
      @Inject
      private LimitProvider limitProvider;
  
      // cache for storing token buckets, where IP is key.
      @Inject
      private javax.cache.Cache<String, byte[]> cache;
  
      private ProxyManager<String> buckets;
  
      @Override
      public void init(FilterConfig filterConfig) throws ServletException {
           // init bucket registry
           buckets = new JCacheProxyManager<>(cache);
      }
  
      @Override
      public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
          HttpServletRequest httpRequest = (HttpServletRequest) servletRequest;
          String userId = AutentificationHelper.getUserIdFromRequest(httpRequest);
  
          // prepare configuration supplier which will be called(on the first interaction with proxy) if the bucket was not saved yet previously.
          Supplier<BucketConfiguration> configurationLazySupplier = getConfigSupplierForUser(userId);
  
          // acquire cheap proxy to the bucket
          Bucket bucket = proxyManager.builder().build(key, configurationLazySupplier);
  
          // tryConsume returns false immediately if no tokens available with the bucket
  