HTTP Session Caching is one of the most used forms of caching in enterprise applications, especially given
the proliferation of Web applications in the enterprise.
HTTP Sessions are primarily used to manage conversational state with users of your Web applications between HTTP
requests given that HTTP is a stateless protocol. This is due to the fact that HTTP connections are not persistent.
When an HTTP client makes a request, the client opens a connection to the server, sends an HTTP request, waits for
the server to process the request and respond, and then closes the connection. Each time an HTTP request is sent,
the same procedure is followed.
Of course, there are alternatives to HTTP when making remote Web Service requests. For instance, if you are using
WebSockets in your applications, then you would have persistent connections
and would most likely be using either the STOMP or WAMP protocols.
The core Spring Framework has first-class support for WebSockets
over the STOMP protocol.
Spring Session additionally supports Session State Management for WebSockets.
As mentioned above, it is useful to use the HTTP Session to manage conversational state with users of your applications
so that they can experience continuity between separate interactions (i.e. HTTP requests). In order to maintain that
continuity and provide a consistent, uninterrupted experience, the HTTP Session must be preserved in a reliable manner.
One way to do this is to employ a data management solution in your application architecture that 1) makes the HTTP
Session highly available and 2) makes the HTTP Session resilient to failures in the system architecture.
Apache Geode is ideal for managing HTTP Session state given that it can distribute data/state across a scaled-out,
highly-available architecture by replicating data in a redundant and organized (partitioned) manner, thereby making
the data resilient to network and hardware failures.
This is ideal in a cloud environment given that you will most likely be running multiple instances of your application
in order to serve the demand, especially during peak loads. In these cases, you will undoubtedly face failures and each
application instance will need to be prepared to take over in a moments notice to provide the consistent, uninterrupted
experience to which we alluded to above. These applications instances will need access to the same HTTP Session state.
An application architecture with HTTP Session State Caching appears as follows:
Essentially, anytime an HTTP Session is requested by your Spring Boot, Web Application, the Servlet Container
(e.g. Apache Tomcat) delegates to Spring Session to provide the implementation of javax.servlet.http.HttpSession.
After all, javax.servlet.http.HttpServlet is an interface that can have many implementations.
Effectively, Spring Session provides it’s own implementation of the javax.servlet.http.HttpSession interface through
a Servlet Filter that gets registered by Spring Session programmatically when Spring Session is on the application
classpath.
Spring Session’s implementation of the javax.servlet.http.HttpSession interface can backed by many different providers
that implement the Spring Session framework’s SessionRepository interface.
Spring Session’s architecture can be depicted as follows:
Again, the SessionRepository interface is the central component of the framework enabling any backend data store
to be adapted and serve as a provider for managing the HTTP Sessions.
This is effectively how Spring Session for Apache Geode
& Pivotal GemFire works.
