为什么我使用Spring Cache在Service中有缓存未命中

[英]Why I have cache misses in Service using Spring Cache


I have configured my cache as follows:

我已按如下方式配置缓存:

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean(name = "caffeineCachingProvider")
    public CachingProvider caffeineCachingProvider() {
        return Caching.getCachingProvider("com.github.benmanes.caffeine.jcache.spi.CaffeineCachingProvider");
    }

    @Bean(name = "caffeineCacheManager")
    public JCacheCacheManager getSpringCacheManager() {
        CacheManager cacheManager = caffeineCachingProvider().getCacheManager();
        CaffeineConfiguration<String, List<Product>> caffeineConfiguration = new CaffeineConfiguration<>();
        caffeineConfiguration.setExpiryPolicyFactory(FactoryBuilder.factoryOf(new AccessedExpiryPolicy(new Duration(TimeUnit.MINUTES, 60))));
        caffeineConfiguration.setCopierFactory(Copier::identity);
        cacheManager.createCache("informerCache", caffeineConfiguration);
        return new JCacheCacheManager(cacheManager);
    }
}

Also I have the @Service that uses it in following way:

我也有@Service以下列方式使用它:

@Service
public class InformerService {

    @CacheResult(cacheName = "informerCache")
    public List<Product> getProducts(@CacheKey String category, @CacheKey String countrySign, @CacheKey long townId) throws Exception {
        Thread.sleep(5000);
        // do some work
    }
}

So I have the next behavior.

所以我有下一个行为。

  1. When I'm calling the service method first time it takes 5 seconds then doing some work as expected.
  2. 当我第一次调用服务方法时需要5秒钟,然后按预期进行一些工作。
  3. Calling method the second time with same parameters - > caching works -> returns result immediately
  4. 第二次使用相同参数调用方法 - >缓存工作 - >立即返回结果
  5. Calling the third time with same parameters again results in Thread.sleep
  6. 再次使用相同参数调用第三次会导致Thread.sleep

And all over again.

并且一遍又一遍。

How to solve this ? Is that the issue about proxying ? What did I miss ?

怎么解决这个?这是关于代理的问题吗?我错过了什么 ?

1 个解决方案

#1


3  

As discussed in the comments, this was a bug in the JCache adapter. Thank you for letting me know about this problem. I released version 2.1.0 which includes this fix. That release also includes friendlier initial settings for CaffeineConfiguration which you identified in another post.

正如评论中所讨论的,这是JCache适配器中的一个错误。感谢您告诉我这个问题。我发布了包含此修复程序的2.1.0版。该版本还包括您在另一篇文章中确定的CaffeineConfiguration更友好的初始设置。

While the core library is heavily tested, the JCache adapters relied too heavily on the JSR's TCK (test compatibility kit). Unfortunately that test suite isn't very effective, so I added tests to help avoid these types of mistakes in the future.

虽然核心库经过严格测试,但JCache适配器过于依赖JSR的TCK(测试兼容性工具包)。不幸的是,测试套件不是很有效,因此我添加了测试以帮助避免将来出现这些类型的错误。

This issue only occurred in JCache because its version of expiration is not supported by Caffeine's core library. Caffeine prefers to use an O(1) design that eagerly cleans up expired entries by using fixed durations. JCache uses per-entry lazy expiration and the specification authors assume a capacity constraint is used to eventually discard expired entries. I added a warning to the documentation about this feature, as it could be error prone. While none of the other JCache implementations go beyond this, a pending task is to decide on a mechanism to help mitigate this JCache design flaw.

此问题仅发生在JCache中,因为Caffeine的核心库不支持其过期版本。咖啡因更喜欢使用O(1)设计,该设计通过使用固定的持续时间来急切地清理过期的条目。 JCache使用每个条目的延迟到期,并且规范作者假设容量约束用于最终丢弃过期的条目。我在文档中添加了有关此功能的警告,因为它可能容易出错。虽然其他JCache实现都没有超出此范围,但一项待定任务是决定一种机制来帮助缓解这种JCache设计缺陷。

Thanks again for reporting this issue. As always, feel free to reach out if you have any other issues or feedback to share.

再次感谢您报告此问题。与往常一样,如果您有任何其他问题或反馈要分享,请随时与我们联系。

智能推荐

注意!

本站翻译的文章,版权归属于本站,未经许可禁止转摘,转摘请注明本文地址:http://www.silva-art.net/blog/2016/01/15/14959b4ca64717d31d4a959ba482ed3c.html



 
© 2014-2019 ITdaan.com 粤ICP备14056181号  

赞助商广告