dcc.Store() component multi-process safe? I know it saves the data in the client, but can I use it with multiple Flask or gunicorn workers? Or will each worker receive a separate copy of that storage/access their own version of it?
I would be absolutely stoked if one of the plotly people could give a short answer to this. I do realize, that some of the more technical questions probably go into the enterprise territory, but it’s really hard to find answers on this kind of stuff.
Hi @klnrdknt I don’t know much about the internals of
dcc.Store but I made some tests to try to answer you. First of all, as a rule of thumb, all Dash core components are meant to work in applications with several sessions at the same time, so you can assume it should be safe. Also, to be sure, I took the code from https://dash.plot.ly/dash-core-components/store (the Store click example) to make a local app, which I opened in two different browsers (for example Firefox and Chrome). If you do the same you will see that for the three kinds of storage there is no influence of one session on the other (interestingly this is not the case for the “session” and “local” mode if you open two tabs in the same browser, probably because the storage is shared between tabs in such a case). So if it’s ok with two different browsers, it should be ok for different users connecting.
Maybe someone from the Dash team can give a more rigorous answer, but I wanted to share with you my heuristic approach ;-).
Hey @Emmanuelle, thanks for the effort. I thought on this a little more and as far as I now understand it, the component is just used to manage local user state. I was interested if the Storage component could also keep some server-side global state, but that probably is not the case.
Still, concerning the workers, I am a little confused. I understand where the component stores stuff, but the workers aka the different processes are a server side feature, either
flask or in my case
gunicorn. When creating the workers, one can either preload the app and hand a copy of all objects to each worker, or create copies of the app on each worker start-up. Concerning python objects, workers do not share the same objects, so any information stored in attributes of classes for example will be different depending on which worker performs a callback task. I’m not sure how these get assigned.
I was wondering where the
Store component lives. So whether it’s like a database-in-memory feature (of the server), where different workers would actually interact with the same stored information, or if each worker has its own
Store component in the backend to work with.
My experience has been pretty much the same as yours, workers and everything work absolutely great for multiple users if each user wants their own represantation of the app and information only needs to be stored locally. This is however not the case, if the app works on some sort of global state. I know
dash enterprise offers a
redis solution, but it’s a little hard to implement myself and I’m only in need of a very minimal solution.