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

Note

The HttpSession with Apache Geode (Client-Server) provides a working sample demonstrating how to integrate Spring Session with Apache Geode to manage the HttpSession using Java configuration. You can read through the basic steps of integration below, but you are encouraged to follow along in the detailed `HttpSession` with Apache Geode (Client-Server) Guide when integrating with your own application.

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.

Client Configuration

Add the following Spring configuration:

@ClientCacheApplication(name = "SpringSessionDataGeodeClientJavaConfigSample", logLevel = "warning",
	pingInterval = 5000L, readTimeout = 15000, retryAttempts = 1, subscriptionEnabled = true) 
@EnableGemFireHttpSession(maxInactiveIntervalInSeconds = 30, poolName = "DEFAULT") 
public class ClientConfig extends IntegrationTestConfig {

	// Required to resolve property placeholders in Spring @Value annotations.
	@Bean
	static PropertySourcesPlaceholderConfigurer propertyPlaceholderConfigurer() {
		return new PropertySourcesPlaceholderConfigurer();
	}

	@Bean
	ClientCacheConfigurer clientCacheServerPortConfigurer(
			@Value("${spring.session.data.geode.cache.server.port:40404}") int port) { 

		return (beanName, clientCacheFactoryBean) ->
			clientCacheFactoryBean.setServers(Collections.singletonList(
				newConnectionEndpoint("localhost", port)));
	}
}

	First, we declare our Web application to be a Apache Geode cache client by annotating our ClientConfig class with @ClientCacheApplication. Additionally, we adjust a few basic, "DEFAULT" Pool settings.
	@EnableGemFireHttpSession creates a Spring bean named springSessionRepositoryFilter that implements javax.servlet.Filter. The filter is what replaces the HttpSession with an implementation provided by Spring Session and backed by Apache Geode. This will also create the necessary client-side Region (by default, "ClusteredSpringSessions`, which is a PROXY Region) corresponding to the same server-side Region by name. All Session state will be sent from the cache client Web application to the server through Region data access operations. The client-side Region will use the "DEFAULT" Pool.
	Then, we adjust the port used by the cache client Pool to connect to the CacheServer using a SDG ClientCacheConfigurer.

Tip

In typical Apache Geode production deployments, where the cluster includes potentially hundreds or thousands of Apache Geode servers (data nodes), it is more common for clients to connect to 1 or more Apache Geode Locators running in the cluster. A Locator passes meta-data to clients about the servers available in the cluster, the server load and which servers have the client’s data of interest, which is particularly important for direct, single-hop data access and latency-sensitive operations. See more details about the Client/Server Deployment in the Apache Geode User Guide.

	Note
	For more information on configuring _Spring Data Geode, refer to the Reference Guide.

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

• clientRegionShortcut - specifies Apache Geode data management policy on the client with a Apache Geode ClientRegionShortcut (default is PROXY). This attribute is only used when configuring a client Region.
• indexableSessionAttributes - Identifies the Session attributes by name that should be indexed for querying operations. Only Session attributes identified by name will be indexed.
• maxInactiveIntervalInSeconds - controls HttpSession idle-timeout expiration (defaults to 30 minutes).
• poolName - name of the dedicated Apache Geode Pool used to connect a client to the cluster of servers. The attribute is only used when the application is a cache client. Defaults to gemfirePool.
• regionName - specifies the name of the Apache Geode Region used to store and manage HttpSession state (default is "ClusteredSpringSessions").
• serverRegionShortcut - specifies Apache Geode data management policy on the server using a Apache Geode RegionShortcut (default is PARTITION). This attribute is only used when configuring server Regions, or when a P2P topology is employed.

Note

It is important to remember that the Apache Geode client Region name must match a server Region by the same name if the client Region is a PROXY or CACHING_PROXY. Client and server Region names are not required to match if the client Region used to store Sessions is LOCAL. However, keep in mind that Session state will not be propagated to the server and you lose all the benefits of using Apache Geode to store and manage distributed, replicated Session state information on the servers in a cluster.

@CacheServerApplication(name = "SpringSessionSampleJavaConfigGemFireClientServer", logLevel = "warning") 
@EnableGemFireHttpSession(maxInactiveIntervalInSeconds = 30) 
public class ServerConfig {

	@SuppressWarnings("resource")
	public static void main(String[] args) throws IOException {
		new AnnotationConfigApplicationContext(ServerConfig.class).registerShutdownHook();
	}

	// Required to resolve property placeholders in Spring @Value annotations.
	@Bean
	static PropertySourcesPlaceholderConfigurer propertyPlaceholderConfigurer() {
		return new PropertySourcesPlaceholderConfigurer();
	}

	@Bean
	CacheServerConfigurer cacheServerPortConfigurer(
			@Value("${spring.session.data.geode.cache.server.port:40404}") int port) { 

		return (beanName, cacheServerFactoryBean) -> {
			cacheServerFactoryBean.setPort(port);
		};
	}
}

Our 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 the ClientConfig class. We also need to ensure our Servlet container (i.e. Tomcat) uses our springSessionRepositoryFilter for every request.

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

You can find an example below:

src/main/java/sample/Initializer.java. 

public class Initializer extends AbstractHttpSessionApplicationInitializer { 

	public Initializer() {
		super(ClientConfig.class); 
	}
}

	Note
	The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.

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

Note

The HttpSession with Apache Geode (Client-Server) using XML provides a working sample demonstrating how to integrate Spring Session with Apache Geode to manage the HttpSession using XML configuration. You can read through the basic steps of integration below, but you are encouraged to follow along in the detailed `HttpSession` with Apache Geode (Client-Server) using XML Guide when integrating with your own application.

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.

Client Configuration

Add the following Spring configuration:

	<context:annotation-config/>

	<context:property-placeholder location="classpath:META-INF/spring/application.properties"/>

	<bean class="sample.ClientServerReadyBeanPostProcessor"/>

	
	<util:properties id="gemfireProperties">
		<prop key="log-level">${spring.session.data.geode.log-level:warning}</prop>
	</util:properties>

	
	<gfe:client-cache properties-ref="gemfireProperties" pool-name="gemfirePool"/>

	
	<gfe:pool ping-interval="5000" read-timeout="15000" retry-attempts="1" subscription-enabled="true">
		<gfe:server host="${application.geode.client-server.host}"
                    port="${spring.session.data.geode.cache.server.port:${application.geode.client-server.port:40404}}"/>
	</gfe:pool>

	
	<bean class="org.springframework.session.data.gemfire.config.annotation.web.http.GemFireHttpSessionConfiguration"
		  p:maxInactiveIntervalInSeconds="30" p:poolName="DEFAULT"/>

	(Optional) First, we can include a Properties bean to configure certain aspects of the Apache Geode ClientCache using GemFire Properties. In this case, we are just setting Apache Geode’s “log-level” from a application-specific System property, defaulting to “warning” if unspecified.
	We must create an instance of an Apache Geode ClientCache initialized with our gemfireProperties.
	Then we configure a Pool of client connections to talk to the Apache Geode Server in our Client/Server topology. In our configuration, we use sensible settings for timeouts, number of connections and so on. Also, our Pool has been configured to connect directly to the server.
	Finally, a GemFireHttpSessionConfiguration bean is registered to enable Spring Session functionality.

Tip

In typical Apache Geode production deployments, where the cluster includes potentially hundreds or thousands of Apache Geode servers (data nodes), it is more common for clients to connect to 1 or more Apache Geode Locators running in the cluster. A Locator passes meta-data to clients about the servers available in the cluster, the server load and which servers have the client’s data of interest, which is particularly important for direct, single-hop data access and latency-sensitive operations. See more details about the Client/Server Deployment in the Apache Geode User Guide.

	Note
	For more information on configuring _Spring Data Geode, refer to the Reference Guide.

Server Configuration

So far, we only covered one side of the equation. We also need an Apache Geode Server for our cache client to talk to and send Session state to the server to manage.

In this sample, we will use the following XML configuration to spin up an Apache Geode Server:

	<context:annotation-config/>

	<context:property-placeholder location="classpath:META-INF/spring/application.properties"/>

	
	<util:properties id="gemfireProperties">
		<prop key="name">SpringSessionSampleXmlGemFireClientServer</prop>
		<prop key="log-level">${spring.session.data.gemfire.log-level:warning}</prop>
<!--
		<prop key="jmx-manager">true</prop>
		<prop key="jmx-manager-start">true</prop>
-->
	</util:properties>

	
	<gfe:cache properties-ref="gemfireProperties"/>

	
	<gfe:cache-server auto-startup="true"
                      bind-address="${application.geode.client-server.host:localhost}"
                      host-name-for-clients="${application.geode.client-server.host:localhost}"
                      port="${spring.session.data.geode.cache.server.port:${application.geode.client-server.port:40404}}"/>

	
	<bean class="org.springframework.session.data.gemfire.config.annotation.web.http.GemFireHttpSessionConfiguration"
		  p:maxInactiveIntervalInSeconds="30"/>

	(Optional) First, we can include a Properties bean to configure certain aspects of the Apache Geode peer Cache using GemFire Properties. In this case, we are just setting Apache Geode’s “log-level” from a application-specific System property, defaulting to “warning” if unspecified.
	We must configure an Apache Geode peer Cache instance initialized with the Apache Geode properties.
	Next, we define a CacheServer with sensible configuration for bind-address and port used by our cache client application to connect to the server to pass Session state.
	Finally, we enable the same Spring Session functionality we declared in the client XML configuration by registering an instance of GemFireHttpSessionConfiguration, except we set the Session expiration timeout to 30 seconds. We explain what this means later.

The Apache Geode Server gets bootstrapped with the following:

@Configuration 
@ImportResource("META-INF/spring/session-server.xml") 
public class ServerConfig {

	public static void main(String[] args) {
		new AnnotationConfigApplicationContext(ServerConfig.class).registerShutdownHook();
	}
}

	Tip
	Rather than defining a simple Java class with a main method, you might consider using Spring Boot instead.

	The @Configuration annotation designates this Java class as a source of Spring configuration meta-data using 7.9. Annotation-based container configuration[Spring’s annotation configuration support].
	Primarily, the configuration comes from the META-INF/spring/session-server.xml file.

Our Spring XML Configuration created a Spring bean named springSessionRepositoryFilter that implements javax.servlet.Filter intervace. 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:

src/main/webapp/WEB-INF/web.xml. 

<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>/WEB-INF/spring/session-client.xml</param-value>
</context-param>
<listener>
	<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

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:

src/main/webapp/WEB-INF/web.xml. 

<filter>
	<filter-name>springSessionRepositoryFilter</filter-name>
	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
	<filter-name>springSessionRepositoryFilter</filter-name>
	<url-pattern>/*</url-pattern>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>ERROR</dispatcher>
</filter-mapping>

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 an HttpSession using Java-based configuration.

	Note
	The HttpSession with Apache Geode (P2P) provides a working sample demonstrating how to integrate Spring Session with Apache Geode to manage the HttpSession using Java configuration. You can read through the basic steps of integration below, but you are encouraged to follow along in the detailed `HttpSession` with Apache Geode (P2P) Guide when integrating with your own application.

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:

@PeerCacheApplication(name = "SpringSessionSampleJavaConfigGemFireP2p", logLevel = "warning") 
@EnableGemFireHttpSession 
@EnableManager(start = true) 
public class Config {

}

	Note
	For more information on configuring _Spring Data Geode, refer to the Reference Guide.

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

Our <<[httpsession-spring-java-configuration-gemfire-p2p,Spring Java Configuration>> created a Spring bean named springSessionRepositoryFilter that implements javasx.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 of these steps extremely easy.

You can find an example below:

src/main/java/sample/Initializer.java. 

public class Initializer extends AbstractHttpSessionApplicationInitializer { 

	public Initializer() {
		super(Config.class); 
	}
}

	Note
	The name of our class (Initializer) does not matter. What is important is that we extend AbstractHttpSessionApplicationInitializer.

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

Note

The HttpSession with Apache Geode (P2P) using XML provides a working sample demonstrating how to integrate Spring Session with Apache Geode to manage the HttpSession using XML configuration. You can read through the basic steps of integration below, but you are encouraged to follow along in the detailed `HttpSession` with Apache Geode (P2P) using XML Guide when integrating with your own application.

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:

src/main/webapp/WEB-INF/spring/session.xml. 

<context:annotation-config/>

<context:property-placeholder/>


<util:properties id="gemfireProperties">
	<prop key="name">SpringSessionSampleXmlGemFireP2p</prop>
	<prop key="log-level">${spring.session.data.geode.log-level:warning}</prop>
	<prop key="jmx-manager">true</prop>
	<prop key="jmx-manager-start">true</prop>
</util:properties>


<gfe:cache properties-ref="gemfireProperties" use-bean-factory-locator="false"/>


<bean class="org.springframework.session.data.gemfire.config.annotation.web.http.GemFireHttpSessionConfiguration"/>

	Tip
	Additionally, we have configured this data node (server) as a Apache Geode Manager as well using Apache Geode-specific JMX properties that enable JMX client (e.g. Gfsh) to connect to this running server.

	Note
	For more information on configuring _Spring Data Geode, refer to the Reference Guide.

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:

src/main/webapp/WEB-INF/web.xml. 

<context-param>
	<param-name>contextConfigLocation</param-name>
	<param-value>
		/WEB-INF/spring/*.xml
	</param-value>
</context-param>
<listener>
	<listener-class>
		org.springframework.web.context.ContextLoaderListener
	</listener-class>
</listener>

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:

src/main/webapp/WEB-INF/web.xml. 

<filter>
	<filter-name>springSessionRepositoryFilter</filter-name>
	<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
	<filter-name>springSessionRepositoryFilter</filter-name>
	<url-pattern>/*</url-pattern>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>ERROR</dispatcher>
</filter-mapping>

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.

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", since GemFire/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 in order to evaluate the query predicate and execute the query. This can be accomplished since Pivotal GemFire and Apache Geode maintains a "Type Registry" containing type meta-data for the objects that get serialized and stored in Apache Geode.

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 where type meta-data is actually stored in the serialized bytes of the object rather than in a separate Type Registry as in Pivotal GemFire and Apache Geode’s case.

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 Pivotal GemFire or Apache Geode 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 customers who only develop and use Native Clients will not provide any Java types for the corresponding C# types.

GemFire and 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 Pivotal GemFire and Apache Geode.

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

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

@Region("People")
class Person {

  private LocalDate birthDate;
  private String name;

  public int getAge() {
    // no explicit 'age' field/property in Person
    // age is just implemented in terms of the 'birthDate' field
  }
}

And, the OQL query invokes a method on a Person object…​

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.

GemFire and Apache Geode do provide the read-serialized configuration setting so that any cache Region.get(key) operations that are potentially invoked inside a Function do 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/Pivotal Pivotal GemFire 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.

	Tip
	While using Java Serialization with Data Serialization and PDX is possible, it is generally preferable and recommended that you use 1 serialization strategy.

	Note
	Unlike Java Serialization, Data Serialization and PDX Serialization do not handle object graph cycles.

More background on Apache Geode Serialization can be found here.

Spring Session for Pivotal GemFire/Apache Geode (SSDG) provides assistance when a user wants to implement a custom SessionSerializer that fits into one of Pivotal GemFire or 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 SSDG’s provided abstract base classes, pertaining to 1 of GemFire/Apache Geode’s Serialization frameworks , then SSDG 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 GemFire/Apache Geode as a org.apache.geode.pdx.PdxSerializer.

Spring Session for Pivotal GemFire/Apache Geode is careful not to stomp on any existing, PdxSerializer implementation that a user may already have registered with the GemFire/Apache Geode cache by some other means. Indeed, several different and provided implementations of the GemFire/Apache Geode org.apache.geode.pdx.PdxSerializer interface do 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 GemFire/Apache Geode cache. The "composite" PdxSerializer implementation is provided Spring Session for Pivotal GemFire/Apache Geode’s org.springframework.session.data.gemfire.pdx.support.ComposablePdxSerializer class when entities are stored in either GemFire or Apache Geode as PDX.

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

Of course, the user is allowed to force the underlying GemFire/Apache Geode Serialization strategy used with his/her custom SessionSerializer implementation by doing 1 of the following…​

Forcing the registration of a custom SessionSerializer as a DataSerializer in GemFire/Apache Geode. 

@EnableGemFireHttpSession(sessionSerializerBeanName = "customSessionSerializer")
class Application {

	@Bean
	DataSerializerSessionSerializerAdapter dataSerializerSessionSerializer() {
		return new DataSerializerSessionSerializerAdapter();
	}

	@Bean
	SessionSerializer<Session, ?, ?> customSessionSerializer() {
		...
	}
}

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

Internally, Spring Session for Pivotal GemFire/Apache Geode maintains 2 representations for the (HTTP) Session and the Session’s attributes. Each representation is based on whether GemFire/Apache Geode "Deltas" are supported or not. GemFire/Apache Geode Delta Propagation is only enabled by Spring Session for Pivotal GemFire/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 Pivotal GemFire/Apache Geode, and for users to provide their own Session related types. The only strict requirement is that the Session implementation must implement the org.springframework.session.Session interface.

By way of example, let’s say the user wants to define their own Session implementation.

First, the user defines their Session type. Perhaps the user’s custom Session type even encapsulates and handles the Session attributes without having to define a separate type.

User-defined Session interface implementation. 

class MySession implements org.springframework.session.Session {
  ...
}

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

Custom SessionRepository implementation creating and returning instances of the custom Session type. 

class MySessionRepository extends GemFireOperationsSessionRepository {

  @Override
  public Session createSession() {
    return new MySession();
  }
}

If the user provided his/her own custom SessionSerializer implementation and GemFire/Apache Geode PDX Serialization is configured, then the user is done.

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

For instance…​

Custom SessionSerializer for custom Session type. 

class MySessionSerializer extends AbstractDataSerializableSessionSerializer {

  @Override
  public Class<?>[] getSupportedClasses() {
    return new Class[] { MySession.class };
  }

  ...
}

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 implementaton. Bu, GemFire/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 basically requires a user to override and implement the getSupportedClasses() method.