- API and implementations (i.e. Redis) for managing a user’s session
- HttpSession – allows replacing the HttpSession in an application container (i.e. Tomcat) neutral way. Additional features include:
- Clustered Sessions – Spring Session makes it trivial to support clustered sessions without being tied to an application container specific solution.
- Multiple Browser Sessions – Spring Session supports managing multiple users’ sessions in a single browser instance (i.e. multiple authenticated accounts similar to Google).
- RESTful APIs – Spring Session allows providing session ids in headers to work with RESTful APIs
- WebSocket – provides the ability to keep the HttpSession alive when receiving WebSocket messages
The magic is done by the
org.springframework.session.web.http.SessionRepositoryFilter that replaces the request object with a wrapper instance providing access to a custom
HttpSession implementation. The sessions are managed by a
org.springframework.session.SessionRepository implementation that is given to the filter. Currently, there are two implementations:
RedisOperationsSessionRepositoryusing Redis as persistence technology
java.util.Mapto hold the session instances. As
Mapimplementation you can use
- a simple
ConcurrentHashMap(e.g. for testing/development purposes)
- a distributed
Mapimplementation provided by Infinispan, Hazelcast or other technologies
- a simple
The interesting part of this is the fact that it works with any servlet container and without special configuration needed for the servlet container. So it’s easy to use Jetty in development and a Tomcat cluster for test and production environments.
Thanks to Spring’s profiles, it’s easy to use a
MapSessionRepository with a
ConcurrentHashMap in development and a distributed implementation when deploying the application to a server.
I think you should definitely have a look at Spring Session in 2015 if you have any of the requirements listed above!