HTTP is a stateless protocol

Session management can be achieved in one of the following ways-

 Cookies
 Hidden form field
 URL Rewriting
 HttpSession

Problems with traditional session management

There are a variety of issues with traditional JavaEE session management that Spring
Session seeks to address. Each of these problems are illustrated with an example
below.

Building a Horizontally Scalable Cloud Native Application

Cloud native application architectures assume that an application will be scaled by

running more instances of the application in Linux containers on a large pool of virtual
machines. For example it is easy to deploy a .war file to Tomcat on Cloud Foundry or
Heroku then scale to 100 app instances with 1GB RAM per instance in a few seconds.
You can also configure the cloud platforms to automatically increase and decrease the
number of application instances based on user demand.

Many application servers store HTTP session state in the same JVM that is running
application code since this is simple to implement and fast. When a new app server
instance joins or leaves the cluster the HTTP sessions are rebalanced over the
remaining app server instances. In an elastic cloud environment where we are running
hundreds of app server instances and where the number of instances can rapidly
increase or decrease at any time, we run into a few problems:
 Rebalancing HTTP sessions can become a performance bottleneck.
 Large heap sizes needed for storing the large number of sessions can cause
garbage collection pauses that impact performance negatively.
 TCP multicast is usually prohibited by cloud infrastructures but it is frequently
used by session managers to discover which app server instances have joined or left a
cluster.

Therefore, it is more efficient to store the HTTP session state in a data store outside the
JVM running your application code. For example 100 instances of Tomcat can be
configured to use Redis for storing session state, and as the number of Tomcat
instances increases or decreases the sessions in Redis are unaffected. Also because
Redis is written in C, it can use hundreds of gigabytes of RAM or maybe even terabytes,
because there is no garbage collector that gets in the way.

For open source servers like Tomcat it is easy to find alternative implementations of the
session manager that use external data stores such as Redis, or Memcached. However
the configuration process can be complex and is specific to each application server. For
closed source products such as WebSphere and Weblogic finding alternative
implementations of their session managers is not only difficult, but often impossible.
Spring Session provides an app server independent way to configure pluggable session
data stores within the bounds of the Servlet specification without having to rely on any
application server specific APIs. This means that Spring Session works with all app
servers (Tomcat, Jetty, WebSphere, WebLogic, JBoss) that implement the servlet spec,
and it is very easy to configure in exactly the same way on all app servers. You also get
to choose whatever external session data store best meets your needs. This makes
Spring Session ideal as a migration tool to help you move traditional JavaEE
applications into the cloud as 12 factor applications.

Multiple Accounts Per User

Imagine that you are running a public facing web application on example.com where
some human users have created multiple accounts. For example, the user Jeff
Lebowski might have two accounts thedude@example.com and
lebowski@example.com. Like other Java web applications you use the HttpSession to
track application state, such as the currently logged in user. So when a human user
wants to switch from thedude@example.com to lebowski@example.com, they have to
logout and then log back in.

With Spring Session it is trivial to configure multiple HTTP sessions per user, enabling
the user to switch between thedude@example.com and lebowski@example.com
without having to logout and login.

Multi-level Security Preview

Imagine you are building a web application with a complex, custom authorization, where
the application UI adapts itself, based on the roles and permissions assigned to a user.

For example, assume that the application has four security levels: public, confidential,
secret, and top secret. When a user logs in to the application, the system figures out
their highest security level and only shows them data that is at their level or below; so a
user who has public clearance can see public docs, and a user that has secret
clearance, can see public, confidential, and secret docs, etc. To make the user interface
more friendly the app should allow users to preview what the app looks like at a lower
security level. For example a top secret user can switch the application from top secret
 mode to secret mode to see how things look like from the point of view of a user with
secret permissions.

Typical web applications store the identity of the current user and their roles in the
HTTP session; but since a web application can only have one session per logged in
user, we won’t be able switch between roles without having to log the user out and then
log them back in, or having to implement multiple sessions per user session on your
own.

Spring Session brings innovation back to the enterprise Java session management
space making it easy to:
 Write horizontally scalable cloud native applications.
 Offload the storage of the session state into specialized external session stores,
such as Redis or Apache Geode, that provide high quality clustering in an application
server independent way.
 Keep the HttpSession alive when users are making requests over WebSocket.
 Access session data from non web request processing code, such as JMS
message processing code.
 Support multiple sessions per browser making it easy to build a richer end-user
experience.
 Control how session ids are exchanged between the client and server making it
easy to write Restful API’s that can extract the session id from an HTTP header rather
than relying on cookies.

Session management has been part of enterprise Java for so long that it has faded to
the background of our consciousness as a solved problem, and we have not seen any
major innovation in that arena in recent memory.

However the modern trend towards micro services and horizontally scalable cloud
native applications challenges the assumptions upon which session managers have
been designed and built for the past 20 years, and exposes flaws in the design of
modern session managers.

This article will demonstrate how the recently released Spring Session
APIs help surmount some of the limitations of the current approach to session
management, traditionally employed by enterprise Java. We will start with a summary of
the problems with current session managers, then dig into the details of how Spring
Session solves each of those problems. We will wrap up the article with a detailed
explanation of how Spring Session works and how you can use it in your projects.

It is important to understand that the core Spring Session project does not depend on
the Spring framework at all, and so you can even use it in projects that don’t use the
Spring framework.
With Spring Session you can easily create multiple sessions per logged in user and
each of those sessions is completely independent of other sessions so implementing
preview functionality is trivial. For example the user that is currently logged in with top
secret role can preview the app in secret mode by having the app create a new session
where the highest security role is secret rather than top secret.

Staying Logged In While Using Web Sockets

Imagine that when users log in to your web application at example.com they can chat
with each other using an HTML5 chat client that works over websockets. According to
the servlet specification requests arriving over websockets don’t keep the HTTP session
alive, and so while your users are chatting, the HTTP session countdown timer is ticking
down. Eventually the HTTP session will expire, even though from the point of view of
the user, they were actively using the application. When the HTTP session expires, the
websocket connection is closed.

With Spring Session you can easily make sure that both websocket requests and
regular HTTP requests keep the HTTP session alive for your users.

Accessing Session Data for non web requests

Imagine that your application offers two ways to access it; one using a REST API over
HTTP, and another via AMQP messages over RabbitMQ. Threads executing the
message processing code don’t have access to the the application server’s
HttpSession, and so you have to come up with a custom solution to gain access to the
data in the the HTTP session through your own mechanism.

With Spring Session you can gain access to the Spring Session from any thread in your
application as long as you know the id of the session. Therefore Spring Session has a
richer API than the Servlet HTTP session manager since you can retrieve very specific
sessions just by knowing the session id. For example, an incoming message might
carry a user id header field that you can use to retrieve the session directly.

How Spring Session Works

Now that we’ve discussed the various use cases where the traditional application server
HTTP session management falls short, lets look at how Spring Session solves the
problem.

Spring Session Architecture

 When implementing a session manager two key problems must be solved. First, how to
create a clustered high availability session that can store data reliably and efficiently.
Second, how to determine which session instance is associated with which incoming
request, whether the request is an HTTP, WebSocket, AMQP or some other protocol.
Essentially the key question is: how is the session id transmitted over the protocol that
is used for making requests?
Spring Session assumes that the first problem of storing data in a high availability
scalable cluster is already well solved by a variety of data stores such as Redis,
GemFire, Apache Geode, etc., and therefore Spring Session should define a standard
set of interfaces that can be implemented to mediate access to the underlying data
store. Spring Session defines the following key interfaces: Session,
ExpiringSession, and SessionRepository, that are implemented for different data stores.

Spring Session Benefits

 Spring Session decouples session management logic from the
application, making it more fault tolerant.
 Spring Session keeps user session information in the database, so it’s
great to use in a clustered environment with multiple server nodes. We don’t
need the sticky session or session replication logic.
 User session data is not lost if the application crashes. When the
application is started again it picks up all the user session data.
 It’s easy to switch between session storage software, just by changing
some configuration we can switch from using Redis to JDBC.
 Spring is an open source project and easily bootstrapped. If you face
any issues, there is a good chance that you will find the solution easily online.

Spring Session consists of the following modules:

 Spring Session Core - provides core Spring Session functionalities and

APIs
 Spring Session Data Redis - provides SessionRepository and
ReactiveSessionRepository implementation backed by Redis and
configuration support
  Spring Session JDBC - provides SessionRepository implementation
backed by a relational database and configuration support
 Spring Session Hazelcast - provides SessionRepository implementation
backed by Hazelcast and configuration support

Spring Session has the simple goal of free up session management from the
limitations of the HTTP session stored in the server.