id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
35498	Race-condition using Django pylibmc implementation (PyLibMCCache)	Bruno Mayer Paixão	nobody	"The Django cache implementation for the pylibmc library (PyLibMCCache) uses the default client, without pooling connections. This library is not thread-safe by default. Although Django stores the cache connections using a thread-safe implementation, a race condition can occur in some scenarios. 

I created an example project to reproduce the problem: [https://github.com/brunomrpx/django-pylibmc-thread-unsafe-example]

The scenario is the following: 
- A Django application with uWSGI and threads enabled, using the FetchFromCacheMiddleware and UpdateCacheMiddleware middlewares
- A route that receives a key to be stored in cache, which is requested by multiple users.
  - If the key doesn't exist in cache, it is stored using the key as the value.
  - If the key exists in cache, the system checks if the key used is the same as the returned value.
  - If the key and value are not the same, a key mismatch occurs.

I'm able to receive a cached view as a result of accessing the cache using a user's key. It also results in users accessing keys stored by other users in a production application. At the end of the README in the example repository there are some suggestions to solve the problem, maybe using the ThreadMappedPool ([https://github.com/brunomrpx/django-pylibmc-thread-unsafe-example/blob/main/cache/cache.py]) would be a good approach. 
"	Uncategorized	closed	Core (Cache system)	3.2	Normal	duplicate	cache pylibmc thread-safe		Unreviewed	0	0	0	0	0	0