HTTP communication is stateless by design, meaning no context is automatically carried from one request to the next. This property aligns well with Spring’s request-processing model, where each HTTP request is handled independently by a thread from the server’s thread pool. However, there are scenarios where RESTful services must retain context across multiple HTTP requests. Common examples include preserving the contents of a shopping cart across user interactions or maintaining user-specific context in agentic AI applications to deliver personalized responses.
To address this requirement, servlet containers such as Tomcat or Jetty provide the concept of an HttpSession. An HTTP session allows state to be associated with a client and reused across subsequent requests, enabling applications to introduce stateful behavior on top of an otherwise stateless protocol.
What is HTTP session?
HTTP sessions (also referred to as a Servlet sessions) are managed by the servlet container and therefore container-specific. A session is typically created when the application explicitly requests it—either by calling HttpServletRequest.getSession() or by accessing a session-scoped attribute during request processing. The session is identified by a unique session identifier, commonly named JSESSIONID. This identifier is sent to the client as part of the HTTP response, usually via a cookie, and is included in subsequent requests so the container can associate those requests with the same session.
An HTTP session typically contains the following information:
Session ID
A unique identifier for the session, commonly represented by JSESSIONID.
Attribute map
A key–value store used to associate state with the session. Keys are strings, and values are arbitrary Java objects—for example, a shopping cart, authenticated user information, or personalization context.
Session metadata
Information such as session creation time, last accessed time, maximum inactive interval, and session validity (active or expired).
The created session is maintained by server by using cookies, among other possible ways. Although HTTP sessions enable applications to introduce stateful behaviour, the default servlet container implementation stores session data in-memory. As a result, subsequent requests carrying the same JSESSIONID must be routed to the same server instance to preserve session continuity.
This model becomes a serious limitation in modern distributed systems, where multiple application instances run behind a load balancer and restarts, redeployments, and scaling events occur frequently. Any deviation in request routing or instance availability can lead to session loss, inconsistent user experience, or forced re-authentication. While it is possible to configure load balancer say, F5 to create sticky sessions where subsequent requests are routed back to same server instance that created the session in the first place. For obvious reasons this is not a clean and scalable solution. This is where Spring Session can be leveraged to provide resilient and scalable session management for Spring-based REST services.
Spring Session
Spring Session is an abstraction that externalises HTTP session management from the servlet container. It integrates with the web request lifecycle by intercepting incoming HTTP requests and delegating session handling to a Spring-managed SessionRepository instead of relying on the container’s in-memory implementation.
While the session identifier is still exchanged with the client, Spring Session manages it independently of the servlet container. By default, the session data can be persisted in an external store such as Redis, a relational database, or another supported backend. This enables session sharing across multiple application instances and eliminates the need for sticky sessions, allowing requests to be freely routed by the load balancer.
In the next blog we shall explore spring session in detail.
Top comments (0)