@CacheEvict will remove all keys of current database

[ramonli]

Recently we upgraded spring-data-redis from 1.X to 2.2.6, and found that @CacheEvict didn't work as we understood in 1.X. Below is our sample code.

    @Cacheable(value = "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG")
    @Override
    public ContentChannelTag queryByPrimaryKey(Long id) {
        return contentChannelTagMapper.selectByPrimaryKey(id);
    }

    @CacheEvict(value = "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG", allEntries = true)
    @Override
    public int deleteByPrimaryKey(Long id) {
        int i = contentChannelTagMapper.deleteByPrimaryKey(id);
        contentChannelTagArticleMergeMapper.deleteByTagId(id); 
        return i;
    }

and a simple testcase:

@Test
public void selectAndDeleteByPrimaryKey() throws Exception {
    ContentChannelTag tag = this.contentChannelTagService.queryByPrimaryKey(7l);
    logger.debug("RESP:{}", JsonUtils.beanToJson(tag));
    int count = this.contentChannelTagService.deleteByPrimaryKey(7l);
    logger.debug("COUNT:{}", count);
}

We monitor the redis commands when running the test cases, the redis commands are as below:

1617933749.723764 [2 192.168.16.29:63711] "INFO"
1617933750.060568 [2 192.168.16.29:63711] "PING"
1617933750.069994 [2 192.168.16.29:63711] "GET" "queryByPrimaryKey:bd703dc0b11593277a5a82dd893f2880b8d0f32a"
1617933750.158564 [2 192.168.16.29:63711] "PING"
1617933750.170874 [2 192.168.16.29:63711] "SET" "queryByPrimaryKey:bd703dc0b11593277a5a82dd893f2880b8d0f32a" "\xac\xed\x00\x05sr\x00Ccom.huize.portal.operation.domain.contentchannel2.ContentChannelTag\xf44^%\xb2h_\xa4\x02\x00\nL\x00\x10createOperatorIdt\x00\x10Ljava/lang/Long;L\x00\x12createOperatorNamet\x00\x12Ljava/lang/String;L\x00\x05isHott\x00\x10Ljava/lang/Byte;L\x00\x16isShowTopAdvertisementq\x00~\x00\x03L\x00\x04nameq\x00~\x00\x02L\x00\x04sortq\x00~\x00\x01L\x00\x05stateq\x00~\x00\x03L\x00\x12topAdvertisementIdq\x00~\x00\x01L\x00\x10updateOperatorIdq\x00~\x00\x01L\x00\x12updateOperatorNameq\x00~\x00\x02xr\x00"com.huize.portal.common.BaseEntity\x82\xb3\r1h\x91\xd36\x02\x00\x04L\x00\ncreateTimet\x00\x10Ljava/util/Date;L\x00\adeletedt\x00\x13Ljava/lang/Boolean;L\x00\x02idq\x00~\x00\x01L\x00\nupdateTimeq\x00~\x00\x05xpsr\x00\x0ejava.util.Datehj\x81\x01KYt\x19\x03\x00\x00xpw\b\x00\x00\x01e\xc6Y\x0f\x10xsr\x00\x11java.lang.Boolean\xcd r\x80\xd5\x9c\xfa\xee\x02\x00\x01Z\x00\x05valuexp\x00sr\x00\x0ejava.lang.Long;\x8b\xe4\x90\xcc\x8f#\xdf\x02\x00\x01J\x00\x05valuexr\x00\x10java.lang.Number\x86\xac\x95\x1d\x0b\x94\xe0\x8b\x02\x00\x00xp\x00\x00\x00\x00\x00\x00\x00\asq\x00~\x00\bw\b\x00\x00\x01e\xcb\x7fk\x10xsq\x00~\x00\x0c\x00\x00\x00\x00\x00\x00\x00\x00t\x00\x00sr\x00\x0ejava.lang.Byte\x9cN`\x84\xeeP\xf5\x1c\x02\x00\x01B\x00\x05valuexq\x00~\x00\r\x00sq\x00~\x00\x12\x01t\x00\r\xe6\x8e\x92\xe5\xba\x8f\xe6\xb5\x8b\xe8\xaf\x951q\x00~\x00\x0eq\x00~\x00\x14sq\x00~\x00\x0c\x00\x00\x00\x00\x00\x00\x00Tsq\x00~\x00\x0c\x00\x00\x00\x00\x00\x00\x00\xdft\x00\t\xe6\xb6\x82\xe9\x92\xb1\xe8\x8b\xb1" "px" "300000"
1617933750.238104 [2 192.168.16.29:63711] "PING"
1617933750.247365 [2 192.168.16.29:63711] "KEYS" "*"
1617933750.255121 [2 192.168.16.29:63711] "DEL" "test" "name" "age" "queryByPrimaryKey:bd703dc0b11593277a5a82dd893f2880b8d0f32a"

What surprised us was that deleteByPrimaryKey will remove all keys in database #2, in our understanding it should only remove all keys in cache PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG.

We found this commit a9c2b1c#diff-3e7270895c24c01ca01a37cc00a9a27cb48e03d2b2d969a764d31b5e29345ea8 which introduced a huge change to RedisCache, seem it doesn't care the Cache any more.

Please let us know whether we got a misunderstanding.

[mp911de]

That isn't something we can reproduce. We observe proper cache prefixing:

1618305301.667577 [0 127.0.0.1:51505] "GET" "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG::1"
1618305301.674692 [0 127.0.0.1:51505] "SET" "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG::1" "\xac\xed\x00\x05t\x00\x05foo 1"
1618305301.675860 [0 127.0.0.1:51505] "GET" "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG::2"
1618305301.676629 [0 127.0.0.1:51505] "SET" "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG::2" "\xac\xed\x00\x05t\x00\x05foo 2"
1618305301.678900 [0 127.0.0.1:51505] "KEYS" "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG::*"
1618305301.679896 [0 127.0.0.1:51505] "DEL" "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG::2" "PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG::1"

RedisCache.clear() considers cache prefixes when scanning for keys to delete. Looking at the monitor output above it seems that your Redis cache doesn't apply prefixing of keys with the cache name (RedisCacheManagerBuilder.withCacheConfiguration("PORTAL_OPERATION_SERVER:CONTENT_CHANNEL_TAG", RedisCacheConfiguration.defaultCacheConfig().disableKeyPrefix())) which can lead to such a case.

If you would like us to spend additional time helping you to diagnose the problem, please provide a minimal sample that reproduces the problem.

[ramonli]

Yes.

we set usePrefix=false

and below is our CacheManager:

    @Override
    @Bean
    public RedisCacheManager cacheManager() {
        RedisCacheConfiguration defaultConfiguration = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofSeconds(this.redisProperties.getCacheableConfig().getTtl()));
        // Here this.redisProperties.getCacheableConfig().getUsePrefix() is false.
        if (!this.redisProperties.getCacheableConfig().getUsePrefix()) {
            defaultConfiguration = defaultConfiguration.disableKeyPrefix();
        }
        if (!this.redisProperties.getCacheableConfig().getCacheNullValues()) {
            defaultConfiguration = defaultConfiguration.disableCachingNullValues();
        }
        RedisCacheManagerBuilder builder = RedisCacheManager.builder(this.redisConnectionFactory).cacheDefaults(defaultConfiguration);
        if (!CollectionUtils.isEmpty(this.redisProperties.getCacheableConfig().getExpires())) {
            Map<String, RedisCacheConfiguration> cacheConfigurationMap = Maps.newHashMap();
            Iterator<String> keyIte = this.redisProperties.getCacheableConfig().getExpires().keySet().iterator();
            while (keyIte.hasNext()) {
                String cacheName = keyIte.next();
                Long value = this.redisProperties.getCacheableConfig().getExpires().get(cacheName);
                cacheConfigurationMap.put(cacheName, defaultConfiguration.entryTtl(Duration.ofSeconds(value)));
            }
            builder.withInitialCacheConfigurations(cacheConfigurationMap);
        }
        return builder.build();
    }

As we learned at spring-data-redis 1.X, if set prefix=false, @CacheEvict will run some redis commands like below:

- "SELECT" "2"     // select database
- "EXISTS" "MyCache_namespace~lock"  // whether lock exists. If exists, wait for lock, otherwise create the lock and hold it.
- "SET" "MyCache_namespace~lock" "MyCache_namespace~lock"     // create and hold lock
- "ZRANGE" "MyCache_namespace~keys" "0" "127"     // query all cache keys which belong to given cache
- "DEL" "\"planId=20140\"" "\"productId=1000265\"" "\"productId=4491\""     // delete all items in given cache
- "DEL" "MyCache_namespace~keys"     // delete key of cache keys
- "DEL" "MyCache_namespace~lock"     // delete lock

It will only remove keys from the given cache. Anyway spring-date-redis shouldn't remove all keys from current database.

[mp911de]

We generally revised the Redis Cache implementation with the 2.0 upgrade. The cache needs to identify the keys that belong to it and with the change the keyspace provides now the information on which keys belong to the cache, specifically when using the prefix. Please enable key prefixes to address your issue.