0

In our history, when we did a new release (deployment) any user who was "logged in" was logged out and that was obviously not ideal. Then I switched platform from a custom stack to a cloud provider and a "managed" platform which seems to have solved the problem. AFAIK a user can stay logged in during a deployment and the state is kept alive. How is it usually solved in practice behind the scenes?

The details are that we first used on-prem combination of tomcat connected to mysql with apache httpd, then replaced everything with Google Appengine.

Improve this question
1
  • Usually, you are dealing with a single page app (SPA) and all user state is kept on the client. If your services are stateless, they can go in and out and requests can be routed without any impact.
    – Berin Loritsch
    Commented Sep 12, 2019 at 18:42

1 Answer 1

Reset to default
3

The trick is to not keep any session state within the stuff you redeploy. Instead:

  • keep state in a separate database that persists beyond a deployment, or
  • keep state purely client-side.

Where a web framework keeps state in-process or in tempfiles, a redeploy necessarily destroys that state. A subtle variant of this is if tokens or keys are generated during startup of the deployed instance, rather than being provided to the instance from some external storage.

I'd strongly recommend looking at the 12 Factor App which discusses how to create web-appish or cloudy software. It recommends that processes should be stateless and disposable, which implies that state must be external of the deployed process.

Improve this answer
3
  • In a deployment on a server would using a cache engine like redis for those tokens be considered premature optimisation? I know that it does not have full persistency but it seems good enough for the general use case.
    – jaskij
    Commented Sep 13, 2019 at 8:37
  • @JanDorniak yes, Redis is a very good fit for a session data database. It has various persistence options. It's not just for caching. In practice, systems that don't pretend that they'd have to be webscale can also get very far with something like SQLite. But from the 12factor perspective any storage or database should be a separate service that's identified by an URL.
    – amon
    Commented Sep 13, 2019 at 8:46
  • that's why I wrote "full persistency" - while I'm not well versed with redis the persistency options I saw so far mean that some data will be lost when it goes down. For sqlite I was actually unaware it supported concurrency, good to know. Although it is still better to be able to have the token data on a separate server (for whatever reasons).
    – jaskij
    Commented Sep 13, 2019 at 9:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.