Stateful vs. Stateless Continuations for Low-Traffic Web Servlets

Session Management Trade-offs

When developing a web application using the Racket web-server, developers can choose between stateful servlets, which store continuations in server memory, and stateless servlets, which serialize continuations into the request or URL.

For a low-traffic workload characterized by long idle gaps between user requests, the primary constraint is the balance between memory overhead and the risk of session expiration. Stateful continuations allow for direct-style coding and lower per-request CPU usage, but they tie memory consumption to the number of active sessions and can lead to failures if a session expires before the user returns.

Conversely, stateless continuations eliminate idle memory pressure and simplify server restarts, but they introduce serialization overhead and require all captured values to be serializable, which may necessitate restructuring the application logic.

Technical Uncertainty

It remains unclear if the reduced architectural complexity of stateful continuations outweighs the operational risks of session timeouts and memory retention in environments where users interact with the service infrequently.

• Does the memory footprint of stateful continuations scale linearly with session count in a way that outweighs the serialization costs of stateless mode for low-traffic sites?
• How do the serializability constraints of stateless servlets impact the ability to capture complex Racket data structures compared to stateful memory storage?