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

Cache extension method does multiple initialization in parallel access #40

Open
rmaenk opened this issue Jul 2, 2019 · 1 comment
Open
Assignees

Comments

@rmaenk
Copy link

rmaenk commented Jul 2, 2019

Hello,

I have detected that Cache extention method does not implement thread-safe initialization.
In our app we are using WEB API and each route uses the same logic for validating access. This logic makes a query to DB to get large set of data. Cache extension helps us improve performance by avoiding this expensive query while data is not changed.

However, if query result is not in cache yet, then multiple requests may occur to DB for the same query.

In our case we are making 3 parallel calls to different WEB API routes( all of them uses the same query to get data for validation). In result in SQL Profiler we see 3 SQL queries instead of 1.
This occurs because processing of the query takes long time, 1-3 sec, and multiple requests to cache from different threads try to initialize the cache.

I have found a good article that describes the same issue in more details and provides interesting fix:
Working with System.Runtime.Caching.MemoryCache

What do you think about this?

From my point of view it would be good to have ability to avoid multiple cache initialization using the way suggested in the article.
It may be good to have separate implementation of Cache extension method from existing one or just add a parameter to existing, that switch internal behavior. Just to minimize side effects for existing applications.

Thanks,
Roman

@JonathanMagnan JonathanMagnan self-assigned this Jul 2, 2019
@JonathanMagnan
Copy link
Member

Hello @roamel ,

That's indeed a very interesting fix. I will look deeper at it later today.

I would say that the current behavior is the expected behavior. However, I'm not sure I would say the same thing in a few hours ;)

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

No branches or pull requests

2 participants