I get it, since this is a class variable, the class is defined at process level (puma worker), each thread (puma thread within the worker) can access the class defined in the process and its variables, so you need it to be thread safe so each thread can define its own value.
Here is the thing. Puma uses thread pools. So a thread might be reutilized from one request to another later. In that case, the class would still have the "threadsafe" var with the old value, and a ContextAlreadyDefinedError would be risen
I get it, since this is a class variable, the class is defined at process level (puma worker), each thread (puma thread within the worker) can access the class defined in the process and its variables, so you need it to be thread safe so each thread can define its own value.
Here is the thing. Puma uses thread pools. So a thread might be reutilized from one request to another later. In that case, the class would still have the "threadsafe" var with the old value, and a ContextAlreadyDefinedError would be risen
I suggest you to use a "clean up mechanism" or use a gem like github.com/ElMassimo/request_store...
quoting the gem:
...values can stick around even after the request is over, since some servers have a pool of Threads that they reuse, which can cause bugs.
using that gem you don't even need the
with
block thing.you can for example in the controller:
and then in the model:
I agree that
request_store_rails
would be an alternative solution for my problems.Maybe I'm missing something but the
with
block is the "clean up mechanism".totally, my bad!