-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
context.Set() doesn't lock the map for writing #273
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
Comments
Each request runs in a separate goroutine so unless you introduce goroutines within, there shouldn't be any problem. Further the underlying map get reset for every new request. |
That must have been my problem then. We were introducing additional goroutines within a request. What was happening was the goroutine for Request 1 was receiving the request ID assigned by the middleware of Request 2. |
In that case, you must acquire a lock while accessing |
With the storage being unexported and no mutex added to the struct how would you recommend to obtain the lock without creating a copy of the Context? |
For an incoming request, a Update: You can also store your own synchronized map in |
Using the withValue seems to work. I'm wondering now what the difference in using the store in the example: What's the difference between:
and
|
|
Appreciate the responses. Closing this. |
So I'm sure this was done on purpose for speed issues but recently ran into an issue where we had a middleware issuing unique Request IDs and saving them using
context.Set()
. Under high concurrency we found that requests began to start sharing request ids and found it was caused by the underlying map for the store not locking.The text was updated successfully, but these errors were encountered: