Resources & lifecycle
How to size a session, and what happens across its lifecycle - running, stopping, and what carries over.
Pick the computing resources your work needs when you start a session; stop the session when you are done to free them. Your data and results stay in the workspace.
What a session costs while it runs
A session uses real computing resources - processor time, memory, storage - on the platform's infrastructure, shared with everyone else using your instance.
Different tools need very different amounts - a lightweight notebook and a heavy imaging application are not comparable - and a session claims what the work inside it requires.
What holds regardless: launch what the analysis needs and no more. A session sitting idle with heavy tools open holds capacity away from colleagues for as long as it exists.
The session lifecycle
A session is either running or stopped.
While it runs it holds your open tools and consumes resources - whether or not you are looking at it. Closing the browser tab does not stop it, which is what you want for a long analysis but easy to forget afterwards.
A session may be stopped after a period of inactivity.
Stopping a session
Stop the session when you have finished, from the dashboard or from the session itself. Its resources return to the pool immediately.
Stopping is not something to avoid. Sessions are meant to be opened and closed freely - the workspace, not the session, is what persists.
What persists, and what does not
One rule covers it: save your work into the workspace.
Data and results written into the workspace's storage are what persists - still there next session, and visible to colleagues working in the same workspace. Anything left only inside the running session, including the live state of your open tools, should not be relied on to survive it stopping.
This is much the same as on a shared computer: files you save survive, things left open do not. Get into the habit of saving into the workspace as you go rather than at the end of a long day.
Why sessions are disposable by design
It would be possible to build a platform where your environment persisted indefinitely, exactly as you left it. CHORUS deliberately does not.
A long-lived personal environment accumulates state nobody can account for - half-finished files, installed extras, configuration that only works on that one machine. It becomes irreproducible, and in a governed environment that is a real problem: if you cannot say what produced a result, you cannot defend it.
Making sessions cheap to discard pushes the durable things - data, code, results - into the workspace, where they are governed, shared, and backed by the project's rules. The session is just the desk you happened to sit at.