How does a framework decide whether to save the session back to its store after a request?

## The store interface behind the session object Whatever the session object looks like in a handler, the framework talks to a much smaller interface underneath, with three operations: - **load(identifier)** — fetch the stored attributes for this client, or report that there are none; - **save(identifier, attributes)** — persist the current attributes; - **destroy(identifier)** — remove the entry entirely, which is what invalidating a session does. Some stores add a fourth, a touch or refresh that extends an entry's life without rewriting its contents. The point of the interface is that it is pluggable: process memory, a shared data store and a database table all satisfy the same three calls, and the handler code above does not change when you swap one for another. ## When each call happens during a request 1. The request arrives carrying an identifier. The framework does **not** load immediately; it defers until the handler first touches the session, so a request that never uses the session costs no store read. 2. On first access, **load** runs once. The attributes are held for the duration of the request, so a handler reading the same attribute ten times performs one store read. 3. The handler reads and writes. Writes go to the in-request copy, not straight to the store. 4. After the handler, before the response finishes, the framework decides whether to call **save**. Step 4 is the interesting one, and it is where frameworks visibly differ. ## Dirty tracking: what marks a session as changed | Operation | Marks dirty | Note | |---|---|---| | Reading an attribute | no | reads never need a write-back | | Storing an attribute | yes | the canonical trigger | | Removing an attribute or clearing | yes | a removal must be persisted too | | Mutating an object already stored, in place | **no** | nothing calls back into the session | | Invalidating the session | n/a | routes to destroy rather than save | The third row is the whole trap. If an attribute holds a collection or a record and the handler modifies that value directly, the session never sees a call and the flag stays clean. With save-if-dirty, nothing is written; the next request loads the old contents and the change has vanished with no error anywhere. Reliable fixes, in order of preference: - **re-store the attribute after mutating it**, so the write path runs; - **keep session values immutable**, so changing one is necessarily a new store; - **mark the session dirty explicitly** where the framework exposes that; - **configure save-always**, accepting a store write on every request that touched the session. ## Save-if-dirty against save-always | | Save if dirty | Save always | |---|---|---| | Store writes | only on change | on every request that used the session | | In-place mutation | silently lost | persisted | | Expiry refresh | needs a touch or a forced save | happens naturally | | Cost under read-heavy traffic | low | one write per request | Neither is universally right. Save-always is forgiving and predictable, and is the safer default when the store is cheap and local; save-if-dirty is what keeps a shared, networked store from taking a write on every page view. The important thing in an interview is to know which one you are relying on, because the in-place mutation bug only exists under the first. ## The concurrency wrinkle Two requests from the same client can overlap — a page and the background call it fired. Both load the same attributes, both modify their own copy, and both save. The second save overwrites the first, so one of the two changes disappears. Dirty tracking does not help here; it only decides *whether* to write, not how to merge. The practical defences are to keep the session small and coarse, to avoid using it as a scratchpad for concurrent work, and to accept that last-write-wins is the semantics on offer. ## What interviewers are listening for The phrase "it saves if something changed" earns partial credit. The full answer connects the three store calls, the once-per-request load, the specific set of operations that mark dirty, and the in-place mutation failure — because that failure is the one that reaches production, produces no exception, and is usually mistaken for a store problem.