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

Potential double invocation of getMissingCache in AbstractCacheManager [SPR-13492] #18070

Closed
spring-projects-issues opened this issue Sep 23, 2015 · 3 comments
Assignees
Labels
in: core type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Sep 23, 2015

Todd Lindner opened SPR-13492 and commented

AbstractCacheManager.getCache(String name) creates caches lazily on access. If the same cache is requested in two different threads it is possible for getMissingCache(name) to be invoked twice.

Suggestion is to add a double-lock mechanism when lookupCache(name) returns null.


Affects: 4.1.7

Issue Links:

  • #16143 Properly wrap runtime-registered caches with TransactionAwareCacheDecorator

Referenced from: commits 75ea6f5

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 24, 2015

Juergen Hoeller commented

Indeed, under this race condition, application code may potentially be using two different Cache references for the same cache, depending on when the getCache calls happened.

I've revised AbstractCacheManager overall for consistent locking when caches get added, in particular also managing the cacheNames Set more defensively in such a scenario.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 24, 2015

Todd Lindner commented

Thanks

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 25, 2015

Juergen Hoeller commented

Note that due to the potential implications of the additional locking here, I'm leaving this as a 4.2.2 only change, not backporting it to 4.1.8.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core type: bug
Projects
None yet
Development

No branches or pull requests

2 participants