Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RedisCache.get(Object, Callable) synchronizes on entire cache instead of individual keys #2890

Closed
Traubenfuchs opened this issue Apr 8, 2024 · 1 comment
Assignees
Labels
type: enhancement A general enhancement

Comments

@Traubenfuchs
Copy link

The following code can be found in org.springframework.data.redis.cache.RedisCache.

	private final Lock lock = new ReentrantLock();

	@Override
	@SuppressWarnings("unchecked")
	public <T> T get(Object key, Callable<T> valueLoader) {

		ValueWrapper result = get(key);

		return result != null ? (T) result.get() : getSynchronized(key, valueLoader);
	}

	@Nullable
	@SuppressWarnings("unchecked")
	private <T> T getSynchronized(Object key, Callable<T> valueLoader) {

		lock.lock();

		try {
			ValueWrapper result = get(key);
			return result != null ? (T) result.get() : loadCacheValue(key, valueLoader);
		} finally {
			lock.unlock();
		}
	}

I believe there could be a significant amount of unnecessary locking happening here.

I don't think that this method should be locked via an instance-global ReentrantLock instance.

Instead, it should be locked on a per key basis, as follows:

        private final ConcurrentHashMap<Object, Lock> keyToLock = new ConcurrentHashMap<>();

	@Nullable
	@SuppressWarnings("unchecked")
	private <T> T getSynchronized(Object key, Callable<T> valueLoader) {

                Lock lock = keyToLock.computeIfAbsent(key, k -> new ReentrantLock());

		lock.lock();

		try {
			ValueWrapper result = get(key);
			return result != null ? (T) result.get() : loadCacheValue(key, valueLoader);
		} finally {
			lock.unlock();
		}
	}

Plus additional cleanup calls to the ConcurrentHashMap for clear and evict calls to RedisCache.

What do you think?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 8, 2024
@mp911de mp911de changed the title Inefficient blocking method call for loading new/expired values? RedisCache.get(Object, Callable) synchronizes on entire cache instead of individual keys Apr 8, 2024
@mp911de
Copy link
Member

mp911de commented Apr 8, 2024

You're right that we lock the entire cache instead of individual keys for value-loading. Back when we implemented this functionality we considered lock-management on a per-key basis a pretty significant overhead.

Cache-locking happens inside RedisCacheWriter. Alternatively, we could reuse RedisCacheWriter's lock and have a lock for the global cache that would also affect other instances of RedisCache on other nodes.

This requires a bit more thought on how refining locking would fit into the bigger picture.

@mp911de mp911de added the for: team-attention An issue we need to discuss as a team to make progress label Apr 8, 2024
@mp911de mp911de self-assigned this Apr 9, 2024
@mp911de mp911de added status: pending-design-work Needs design work before any code can be developed and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 9, 2024
@mp911de mp911de added type: enhancement A general enhancement and removed status: pending-design-work Needs design work before any code can be developed for: team-attention An issue we need to discuss as a team to make progress labels Jul 29, 2024
@christophstrobl christophstrobl added this to the 3.4 M1 (2024.1.0) milestone Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants