Spring Session

This section describes how to configure Apache Geode’s Client-Server topology to manage HttpSession state with Java-based configuration.

After adding the required dependencies and repository declarations, we can create the Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the HttpSession with an implementation backed by Spring Session and Apache Geode.

This section describes how to configure Apache Geode’s Client-Server topology to manage HttpSession state with XML-based configuration.

After adding the required dependencies and repository declarations, we can create the Spring configuration. The Spring configuration is responsible for creating a Servlet Filter that replaces the javax.servlet.http.HttpSession with an implementation backed by Spring Session and Apache Geode.

Our Spring XML Configuration created a Spring bean named springSessionRepositoryFilter that implements javax.servlet.Filter interface. The springSessionRepositoryFilter bean is responsible for replacing the javax.servlet.http.HttpSession with a custom implementation that is provided by Spring Session and Apache Geode.

In order for our Filter to do its magic, we need to instruct Spring to load our session-client.xml configuration file.

We do this with the following configuration:

The ContextLoaderListener reads the contextConfigLocation context parameter value and picks up our session-client.xml configuration file.

Finally, we need to ensure that our Servlet container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request.

The following snippet performs this last step for us:

The DelegatingFilterProxy will look up a bean by the name of springSessionRepositoryFilter and cast it to a Filter. For every HTTP request, the DelegatingFilterProxy is invoked, which delegates to the springSessionRepositoryFilter.

This section describes how to configure Apache Geode’s Peer-To-Peer (P2P) topology to manage HttpSession state using Java-based configuration.

After adding the required dependencies and repository declarations, we can create the Spring configuration.

The Spring configuration is responsible for creating a Servlet Filter that replaces the javax.servlet.http.HttpSession with an implementation backed by Spring Session and Apache Geode.

Add the following Spring configuration:

The @EnableGemFireHttpSession annotation enables developers to configure certain aspects of both Spring Session and Apache Geode out-of-the-box using the following attributes:

Our <<[httpsession-spring-java-configuration-p2p,Spring Java Configuration>> created a Spring bean named springSessionRepositoryFilter that implements javax.servlet.Filter. The springSessionRepositoryFilter bean is responsible for replacing the javax.servlet.http.HttpSession with a custom implementation backed by Spring Session and Apache Geode.

In order for our Filter to do its magic, Spring needs to load our Config class. We also need to ensure our Servlet container (i.e. Tomcat) uses our springSessionRepositoryFilter on every HTTP request.

Fortunately, Spring Session provides a utility class named AbstractHttpSessionApplicationInitializer to make both steps extremely easy.

You can find an example below:

This section describes how to configure Apache Geode’s Peer-To-Peer (P2P) topology to manage HttpSession state using XML-based configuration.

After adding the required dependencies and repository declarations, we can create the Spring configuration.

The Spring configuration is responsible for creating a Servlet Filter that replaces the javax.servlet.http.HttpSession with an implementation backed by Spring Session and Apache Geode.

Add the following Spring configuration:

The Spring XML Configuration created a Spring bean named springSessionRepositoryFilter that implements javax.servlet.Filter. The springSessionRepositoryFilter bean is responsible for replacing the javax.servlet.http.HttpSession with a custom implementation that is backed by Spring Session and Apache Geode.

In order for our Filter to do its magic, we need to instruct Spring to load our session.xml configuration file.

We do this with the following configuration:

The ContextLoaderListener reads the contextConfigLocation context parameter value and picks up our session.xml configuration file.

Finally, we need to ensure that our Servlet container (i.e. Tomcat) uses our springSessionRepositoryFilter for every HTTP request.

The following snippet performs this last step for us:

The DelegatingFilterProxy will look up a bean by the name of springSessionRepositoryFilter and cast it to a Filter. For every HTTP request the DelegatingFilterProxy is invoked, delegating to the springSessionRepositoryFilter.

By way of example, consider the following configuration:

In addition, consider the following Spring Boot application.properties file:

The Session expiration timeout will be 300 seconds, or 5 minutes, overriding both the property (i.e. spring.session.data.gemfire.session.expiration.max-inactive-interval-seconds) of 900 seconds, or 15 minutes, as well as the explicit @EnableGemFireHttpSession.maxInactiveIntervalInSeconds annotation attribute value of 3600 seconds, or 1 hour.

Since the "sessionExpirationTimeoutConfigurer" bean does not override the getRegionName() method, the Session Region name will be determined by the property (i.e. spring.session.data.gemfire.session.region.name), set to "Sessions", which overrides the implicit @EnableGemFireHttpSession.regionName annotation attribute’s default value of "ClusteredSpringSessions".

The @EnableGemFireHttpSession.poolName annotation attribute’s value of "DEFAULT" will determine the name of the Pool used when sending Region operations between the client and server to manage Session state on the server(s) since neither the corresponding property (i.e. spring.session.data.gemfire.cache.client.pool.name`) was set nor was the SpringSessionGemFireConfigurer.getPoolName() method overridden by the "sessionExpirationTimeoutConfigurer" bean.

And finally, the client Region used to manage Session state will have a data management policy of PROXY, the default value for the @EnableGemFireHttpSession.clientRegionShortcut annotation attribute, which was not explicitly set, nor was the corresponding property (i.e. spring.session.data.gemfire.cache.client.region.shortcut) for this attribute. And, because the SpringSessionConfigurer.getClientRegionShortcut() method was not overridden, the default value is used.

Data Serialization is a very efficient format (i.e. fast and compact), with little overhead when compared to Java Serialization.

It supports Delta Propagation by sending only the bits of data that actually changed as opposed to sending the entire object, which certainly cuts down on the amount of data sent over the network in addition to reducing the amount of IO when data is persisted or overflowed to disk.

However, Data Serialization incurs a CPU penalty anytime data is transferred over-the-wire, or persisted/overflowed to and accessed from disk, since the receiving end performs a deserialization. In fact, anytime Delta Propagation is used, the object must be deserialized on the receiving end in order to apply the "delta". Apache Geode applies deltas by invoking a method on the object that implements the org.apache.geode.Delta interface. Clearly, you cannot invoke a method on a serialized object.

PDX, on the other hand, which stands for Portable Data Exchange, retains the form in which the data was sent. For example, if a client sends data to a server in PDX format, the server will retain the data as PDX serialized bytes and store them in the cache Region for which the data access operation was targeted.

Additionally, PDX, as the name implies, is "portable", meaning it enables both Java and Native Language Clients, such as C, C++ and C# clients, to inter-operate on the same data set.

PDX even allows OQL queries to be performed on the serialized bytes without causing the objects to be deserialized first in order to evaluate the query predicate and execute the query. This can be accomplished since Apache Geode maintains a "Type Registry" containing type meta-data for the objects that get serialized and stored in Apache Geode using PDX.

However, portability does come with a cost, having slightly more overhead than Data Serialization. Still, PDX is far more efficient and flexible than Java Serialization, which stores type meta-data in the serialized bytes of the object rather than in a separate Type Registry as in Apache Geode’s case when using PDX.

PDX does not support Deltas. Technically, a PDX serializable object can be used in Delta Propagation by implementing the org.apache.geode.Delta interface, and only the "delta" will be sent, even in the context of PDX. But then, the PDX serialized object must be deserialized to apply the delta. Remember, a method is invoked to apply the delta, which defeats the purpose of using PDX in the first place.

When developing Native Clients (e.g. C) that manage data in a {data-store-name} cluster, or even when mixing Native Clients with Java clients, typically there will not be any associated Java types provided on the classpath of the servers in the cluster. With PDX, it is not necessary to provide the Java types on the classpath, and many users who only develop and use Native Clients to access data stored in {data-store-name} will not provide any Java types for their corresponding C/C/C# types.

Apache Geode also support JSON serialized to/from PDX. In this case, it is very likely that Java types will not be provided on the servers classpath since many different languages (e.g. JavaScript, Python, Ruby) supporting JSON can be used with Apache Geode.

Still, even with PDX in play, users must take care not to cause a PDX serialized object on the servers in the cluster to be deserialized.

For example, consider an OQL query on an object of the following Java type serialized as PDX…​

Subsequently, if the OQL query invokes a method on a Person object, such as:

SELECT * FROM /People p WHERE p.age >= 21

Then, this is going to cause a PDX serialized Person object to be deserialized since age is not a field of Person, but rather a method containing a computation based on another field of Person (i.e. birthDate). Likewise, calling any java.lang.Object method in a OQL query, like Object.toString(), is going to cause a deserialization to happen as well.

Apache Geode does provide the read-serialized configuration setting so that any cache Region.get(key) operations that are potentially invoked inside a Function does not cause PDX serialized objects to be deserialized. But, nothing will prevent an ill-conceived OQL query from causing a deserialization, so be careful.

It is possible for Apache Geode to support all 3 serialization formats simultaneously.

For instance, your application domain model might contain objects that implement the java.io.Serialiable interface, and you may be using a combination of the Data Serialization framework along with PDX.

More background on Apache Geode’s serialization mechanics can be found here.

Spring Session for Apache Geode provides assistance when a user wants to implement a custom SessionSerializer that fits into one of Apache Geode’s Serialization frameworks.

If the user just implements the org.springframework.session.data.gemfire.serialization.SessionSerializer interface directly without extending from one of Spring Session for Apache Geode’s provided abstract base classes, related to 1 of Apache Geode’s Serialization frameworks , then Spring Session for Apache Geode will wrap the user’s custom SessionSerializer implementation in an instance of org.springframework.session.data.gemfire.serialization.pdx.support.PdxSerializerSessionSerializerAdapter and register it with Apache Geode as a org.apache.geode.pdx.PdxSerializer.

Spring Session for Apache Geode is careful not to stomp on any existing PdxSerializer implementation that a user may have already registered with Apache Geode by some other means. Indeed, several different, provided implementations of Apache Geode’s org.apache.geode.pdx.PdxSerializer interface exists:

This is accomplished by obtaining any currently registered PdxSerializer instance on the cache and composing it with the PdxSerializerSessionSerializerAdapter wrapping the user’s custom application SessionSerializer implementation and re-registering this "composite" PdxSerializer on the Apache Geode cache. The "composite" PdxSerializer implementation is provided by Spring Session for Apache Geode’s org.springframework.session.data.gemfire.pdx.support.ComposablePdxSerializer class when entities are stored in Apache Geode as PDX.

If no other PdxSerializer was currently registered with the Apache Geode cache, then the adapter is simply registered.

Of course, you are allowed to force the underlying Apache Geode Serialization strategy used with a custom SessionSerializer implementation by doing 1 of the following:

Just by the very presence of the DataSerializerSessionSerializerAdapter registered as a bean in the Spring container, any neutral custom SessionSerializer implementation will be treated and registered as a DataSerializer in Apache Geode.

By default, anytime the Session is modified (e.g. the lastAccessedTime is updated to the current time), the Session is considered dirty by Spring Session for Apache Geode (SSDG). When using Apache Geode Data Serialization framework, it is extremely useful and valuable to take advantage of Apache Geode’s Delta Propagation capabilities as well.

When using Data Serialization, SSDG also uses Delta Propagation to send only changes to the Session state between the client and server. This includes any Session attributes that may have been added, removed or updated.

By default, anytime Session.setAttribute(name, value) is called, the Session attribute is considered "dirty" and will be sent in the delta between the client and server. This is true even if your application domain object has not been changed.

Typically, there is never a reason to call Session.setAttribute(..) unless your object has been changed. However, if this can occur, and your objects are relatively large (with a complex object hierarchy), then you may want to consider either:

Out of the box, SSDG provides 5 implementations of the IsDirtyPredicate strategy interface:

As shown in the table above, the DeltaAwareDirtyPredicate is the default implementation used by SSDG. The DeltaAwareDirtyPredicate automatically takes into consideration application domain objects that implement the Apache Geode Delta interface. However, DeltaAwareDirtyPredicate works even when your application domain objects do not implement the Delta interface. SSDG will consider your application domain object to be dirty anytime the Session.setAttribute(name, newValue) is called providing the new value is not the same as old value, or the new value does not implement the Delta interface.

You can change SSDG’s dirty implementation, determination strategy simply by declaring a bean in the Spring container of the IsDirtyPredicate interface type:

Internally, Spring Session for Apache Geode maintains 2 representations of the (HTTP) Session and the Session’s attributes. Each representation is based on whether Apache Geode "Deltas" are supported or not.

Apache Geode Delta Propagation is only enabled by Spring Session for Apache Geode when using Data Serialization for reasons that were discussed earlier.

Effectively, the strategy is:

It is possible to override these internal representations used by Spring Session for Apache Geode, and for users to provide their own Session related types. The only strict requirement is that the Session implementation must implement the core Spring Session org.springframework.session.Session interface.

By way of example, let’s say you want to define your own Session implementation.

First, you define the Session type. Perhaps your custom Session type even encapsulates and handles the Session attributes without having to define a separate type.

Then, you would need to extend the org.springframework.session.data.gemfire.GemFireOperationsSessionRepository class and override the createSession() method to create instances of your custom Session implementation class.

If you provide your own custom SessionSerializer implementation and Apache Geode PDX Serialization is configured, then you done.

However, if you configured Apache Geode Data Serialization then you must additionally provide a custom implementation of the SessionSerializer interface and either have it directly extend Apache Geode’s org.apache.geode.DataSerializer class, or extend Spring Session for Apache Geode’s org.springframework.session.data.gemfire.serialization.data.AbstractDataSerializableSessionSerializer class and override the getSupportedClasses():Class<?>[] method.

For example:

Unfortunately, getSupportedClasses() cannot return the generic Spring Session org.springframework.session.Session interface type. If it could then we could avoid the explicit need to override the getSupportedClasses() method on the custom DataSerializer implementation. But, Apache Geode’s Data Serialization framework can only match on exact class types since it incorrectly and internally stores and refers to the class type by name, which then requires the user to override and implement the getSupportedClasses() method.