Add option to use compression

[candrews]

Spring Session uses Java serialization to convert objects to bytes which are then persisted. Java's serialization format is quite verbose and it compresses very well - it would be nice to offer optional compression for the serialized byte data. Doing so would use less persistent storage and transfer less data over the network, and in at least some situations result in an overall performance improvement.

Using Java's GZIPInputStream/GZIPOutputStream seems like a great option, as it would introduce no new dependencies and work everywhere.

[candrews]

@vpavic if you think this would be acceptable, I can prepare a PR.

[vpavic]

Thanks @candrews. From the description, it's not clear whether you are suggesting this for a specific SessionRepository implementation or in general. However having in mind you previous reports/PRs, I suspect this is about JdbcOperationsSessionRepository?

Flexibility in choice of serialization mechanism should be provided, since the serialization itself can have a significant impact on performance. Rather than changing our defaults, I think we should look into providing configuration facilities for customizing serialization mechanism in JdbcOperationsSessionRepository and HazelcastSessionRepository. PRs are definitely welcome! 🙂

[candrews]

There are ways to do this today, but they're far from intuitive/simple and they're different for each repository implementation.

JdbcOperationsSessionRepository (see the serialize and deserialize methods) uses a ConversionService to convert Objects to byte[] (which can be set to a custom implementation using the setConversionService method). The ConversionService can therefore do the compression.

RedisOperationsSessionRepository doesn't use a ConversionService. Instead, it uses RedisSerializer<Object> to serialize/deserialize, and this can be set using setDefaultSerializer. Providing a custom implementation of RedisSerializer<Object>.

So those two are completely different.

Which way should we go? Options include:

• Change all repositories to do Object<->byte[] conversion using ConversionService and all use the same springSessionConversionService bean by default (like JdbcOperationsSessionRepository and it's configuration in JdbcHttpSessionConfiguration), then provide a configuration option that, when enabled, wraps that ConversionService with compression when doing Object<->byte[] conversion
• Introduce a new interface specifically for compression, SpringSessionCompressionService with two methods: byte[] compress(@Nullable byte[] data) and byte[] decompress(@Nullable byte[] data) (Instead of byte[], InputStream and OutputStream may be better?). Repository implementations gain a setter so they can get access to this service, and they use it whenever reading/writing to their backing stores. Include a NoOpSpringSessionCompressionService (which does nothing) implementation which is used by default, and also a GZIPSpringSessionCompressionService implementation (which uses GZIPInputStream/GZIPOutputStream).
• Combination of these two. Make the changes from the first option, and use SpringSessionCompressionService to perform the compression in the ConversionService.

Thoughts? I'd like some feedback before I go spending a bunch of time going down this particular rabbit hole. :) Thanks!

[candrews]

@vpavic thoughts?

[candrews]

@vpavic @rwinch bump

[rwinch]

I think the first step would be to ensure custom serialization mechanisms are in place for each repository type. Then providing a serialization mechanism that performs the compression.

[candrews]

I think the first step would be to ensure custom serialization mechanisms are in place for each repository type.

👍

Then providing a serialization mechanism that performs the compression.

👎 I think serialization and compression as related, but not one in the same (they shouldn't be linked). My choice of compression shouldn't be dependent on my choice of serialization. I should be able to use Java serialization with bzip, for example, without having to write my own JavaSerializationWithBzipCompression class.

[vpavic]

Regarding the support for custom serialization in JdbcOperationsSessionRepository, you can track #1166.

I think serialization and compression as related, but not one in the same (they shouldn't be linked). My choice of compression shouldn't be dependent on my choice of serialization.

This is one of those things that adds complexity for a very specific use case - to my knowledge you're the only one who requested compression. Let's start with #1166 as that will provide you a way to meet your requirement.

[vpavic]

Note that I've just closed #1166 as we already support custom serialization via JdbcHttpSessionConfiguration#setConversionService. Having this in mind @candrews, you should already be able to meet your requirement with a custom ConversionService.

[vpavic]

Closing as we're not keen to add this ATM, and JdbcHttpSessionConfiguration already offers a way to customize serialization.