Spring Session JDBC is a great way to allow an application to be stateless. By storing the session in the database, a request can be routed to any application server. This approach provides significant advantages such as automatic horizontal scaling, seamless failover, and no need for session affinity. By using JDBC, the database the application is already using provides the storage avoiding the need to setup and maintain other software, such as Memcache or Redis.

When Spring Session JDBC stores the session in the database, it has to serialize (convert from a Java object to a string) the session and also deserialize it (convert from a string back to a Java object). By default, it uses Java’s built in serialization.

There are numerous reasons not to use Java’s built in serialization (ObjectInputSteam / ObjectOutputStream). Oracle calls it a “Horrible Mistake” and plans to remove it in a future Java release. It’s also less performant and produces a larger serialized form than many alternatives.

Since Java serialization is (at least, for now) included in Java, it’s still commonly used, including by Spring Session JDBC. Switching to another serialization method can be a relatively quick and easy way to improve performance.

Any serialization can be used, including Jackson (which uses the JSON or XML format), Protocol Buffers, Avro, and more. However, all require work to define schemas for the data and additional configuration. In the interest of avoiding those efforts (which is especially important for legacy applications), a schemaless serializer (which is what Java’s built in serializer is) can be used such as FST (fast-serializer) or Kryo.

Switching the serializer used by Spring Session JDBC is done by defining a a bean named springSessionConversionService of type ConversionService. The following examples provide the code to use FST or Kryo.

Using FST with Spring Session JDBC

Add FST as dependency to the project. For example, using Maven:

<dependency> <groupId>de.ruedigermoeller</groupId> <artifactId>fst</artifactId> <version>2.56</version> </dependency>

And these add these classes:

FstSessionConfig.java

import org.springframework.beans.factory.BeanClassLoaderAware; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.core.convert.ConversionService; import org.springframework.core.convert.support.GenericConversionService; import org.springframework.core.serializer.support.DeserializingConverter; import org.springframework.core.serializer.support.SerializingConverter; @Configuration public class FstSessionConfig implements BeanClassLoaderAware { private ClassLoader classLoader; @Bean public ConversionService springSessionConversionService() { final FstDeserializerSerializer fstDeserializerSerializer = new FstDeserializerSerializer(classLoader); final GenericConversionService conversionService = new GenericConversionService(); conversionService.addConverter(Object.class, byte[].class, new SerializingConverter(fstDeserializerSerializer)); conversionService.addConverter(byte[].class, Object.class, new DeserializingConverter(fstDeserializerSerializer)); return conversionService; } @Override public void setBeanClassLoader(final ClassLoader classLoader) { this.classLoader = classLoader; } }

FstDeserializerSerializer.java

import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import org.nustaq.serialization.FSTConfiguration; import org.nustaq.serialization.FSTObjectOutput; import org.springframework.core.NestedIOException; import org.springframework.core.serializer.Deserializer; import org.springframework.core.serializer.Serializer; public class FstDeserializerSerializer implements Serializer<Object>, Deserializer<Object> { private final FSTConfiguration fstConfiguration; public FstDeserializerSerializer(final ClassLoader classLoader) { fstConfiguration = FSTConfiguration.createDefaultConfiguration(); fstConfiguration.setClassLoader(classLoader); } @Override public Object deserialize(InputStream inputStream) throws IOException { try{ return fstConfiguration.getObjectInput(inputStream).readObject(); } catch (ClassNotFoundException ex) { throw new NestedIOException("Failed to deserialize object type", ex); } } @Override public void serialize(Object object, OutputStream outputStream) throws IOException { // Do not close fstObjectOutput - that would prevent reuse and cause an error // see https://github.com/RuedigerMoeller/fast-serialization/wiki/Serialization @SuppressWarnings("resource") final FSTObjectOutput fstObjectOutput = fstConfiguration.getObjectOutput(outputStream); fstObjectOutput.writeObject(object); fstObjectOutput.flush(); } }

Using Kryo with Spring Session JDBC

Add Kryo as dependency to the project. For example, using Maven:

<dependency> <groupId>com.esotericsoftware</groupId> <artifactId>kryo</artifactId> <version>5.0.0-RC4</version> </dependency>

And these add these classes:

KryoSessionConfig.java

import org.springframework.beans.factory.BeanClassLoaderAware; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.core.convert.ConversionService; import org.springframework.core.convert.support.GenericConversionService; import org.springframework.core.serializer.support.DeserializingConverter; import org.springframework.core.serializer.support.SerializingConverter; @Configuration public class KryoSessionConfig implements BeanClassLoaderAware { private ClassLoader classLoader; @Bean public ConversionService springSessionConversionService() { final KryoDeserializerSerializer kryoDeserializerSerializer = new KryoDeserializerSerializer(classLoader); final GenericConversionService conversionService = new GenericConversionService(); conversionService.addConverter(Object.class, byte[].class, new SerializingConverter(kryoDeserializerSerializer)); conversionService.addConverter(byte[].class, Object.class, new DeserializingConverter(kryoDeserializerSerializer)); return conversionService; } @Override public void setBeanClassLoader(final ClassLoader classLoader) { this.classLoader = classLoader; } }

KryoDeserializerSerializer.java

import java.io.IOException; import java.io.InputStream; import java.io.OutputStream; import org.springframework.core.serializer.Deserializer; import org.springframework.core.serializer.Serializer; import com.esotericsoftware.kryo.Kryo; import com.esotericsoftware.kryo.io.Input; import com.esotericsoftware.kryo.io.Output; import com.esotericsoftware.kryo.util.Pool; public class KryoDeserializerSerializer implements Serializer<Object>, Deserializer<Object> { private final ClassLoader classLoader; // Pool constructor arguments: thread safe, soft references, maximum capacity private final Pool<Kryo> kryoPool = new Pool<Kryo>(true, true) { protected Kryo create () { final Kryo kryo = new Kryo(); kryo.setClassLoader(classLoader); kryo.setRegistrationRequired(false); return kryo; } }; public KryoDeserializerSerializer(final ClassLoader classLoader) { this.classLoader = classLoader; } @Override public Object deserialize(InputStream inputStream) throws IOException { final Kryo kryo = kryoPool.obtain(); try(final Input input = new Input(inputStream)){ return kryo.readObjectOrNull(input, null); }finally { kryoPool.free(kryo); } } @Override public void serialize(Object object, OutputStream outputStream) throws IOException { final Kryo kryo = kryoPool.obtain(); try(final Output output = new Output(outputStream)){ kryo.writeObject(output, object); }finally { kryoPool.free(kryo); } } }

How to Choose which Serializer to Use

The process of selecting which serializer to use for an application should be done only through testing, both for functionality and for performance.

For some applications, a serializer won’t work due to known limitations in the serializer or bugs in it. For example, FST doesn’t currently support the Java 8 time classes, so if your application stores session data using such a class, FST is not for you. With Kryo, I ran into a bug stopping me from using it (which will be fixed in version 5.0.0-RC5 and later).

Performance will also vary between serializers for each application. Factors that impact performance include exactly what is being serialized, how big that data is, how often it’s accessed, the version of Java, and how the system is configured. FST has published some benchmarks, but that information must be taken with a grain of salt as those benchmarks are only measuring very specific, isolated scenarios. That data does provide general guidance though – you can expect better performance when you switch from the Java serializer to FST, for example, but testing of the full application will need to be done to determine if the improvement is 0.1% or 10%.