If it looks like I’m thinking out loud, here, it’s because I am. It helps get context (and its requirements) out in the open, where others can chime in with questions and ideas.
My app uses a commonplace timer-based session-extension technique (I call it a “user heartbeat”). It allows users to remain connected during entry of complex data. So its primary issue is not “how do I prevent users from logging in”, but how do I make sure that currently-connected users disconnect, and stay disconnected, until the coast is clear.
I think I’ll have to extend the overall “heartbeat” mechanism so that it can
- tell when a shutdown is needed
- save the user’s data and log out
- prevent the user from logging back in.
- allow them to log back in once the shutdown has ended
Equally, server-side, I have to know when all users have logged out, so that the corresponding maintenance steps know when they can proceed safely.
This is somewhat complicated by the fact that a user may be logged in from several different browser tabs simultaneously, often, without even knowing it. For example, they may have started working on their data during lunch hour at work, and want to continue that work at home, having left work with their work browser minimized and forgotten, but not actually closed.
This makes it clear that we should not be talking about users, per se, but user-sessions. A list of active sessions would be needed. When this list shrinks to empty, then maintenance can proceed.
There are scores of different things that might trigger a shutdown: data backups/restores; bug fixes (server-side, client-side, or both); changes in third-party services (including those provided via Uplink); database content/structure changes; visual updates; …
Fortunately, the mechanism doesn’t have to care about causes. It need only concern itself with effects.