Understanding Cookie + Session Mechanism and Distributed Session Sharing Solutions

HTTP is a stateless protocol, so web applications use the Cookie + Session mechanism to keep a user's session continuous. When a client requests the server, the server creates a Session object, stores user data, generates a sessionID , and sends it back via the Set-Cookie: JSESSIONID=XXXXXXX header. The client stores the sessionID in a cookie.

Storing all data in a cookie is impractical because cookies have length limits, increase network traffic, and expose data to the client, creating security risks. Therefore, most data is kept on the server side in the session.

A session remains active while the client continues to interact with the server; once the session expires, the user is considered logged out.

If cookies are disabled, the common fallback is to pass the sessionID as a URL parameter.

In a distributed architecture, a request may be routed to different servers. Server A may create a session, but when the next request is handled by Server B, the session does not exist, causing the user to be logged out unexpectedly.

Typical solutions include:

Session Replication : synchronize session data across all servers. This adds network bandwidth overhead and memory consumption on each node.

Session Sticky : configure the load balancer to route all requests with the same session ID to the same server. This creates a stateful load balancer and risks session loss if a server fails.

Centralized Session Store : store sessions in an external system such as Redis or MySQL, allowing all servers to retrieve session data from a single source. This introduces a single point of failure and adds dependency on the external store.

Because these approaches complicate scaling, the article recommends using ThreadLocal for small‑to‑medium web applications. ThreadLocal provides a thread‑local variable that holds user data for the duration of a request, ensuring isolation between threads.

A typical usage pattern is to create a servlet filter that, on each request, retrieves the logged‑in user (optionally from Redis) and stores it in a ThreadLocal . After the request is processed, the filter clears the ThreadLocal to avoid memory leaks.

Example code for creating a cookie:

Cookie cookie = new Cookie("username","helloweenvsfei");
cookie.setMaxAge(Integer.MAX_VALUE);
response.addCookie(cookie);

Images illustrating the distributed session problem and the sticky load‑balancing approach are included in the original article.