Support Sticky Sessions

[rwinch]

When a client is using sticky sessions, there could be certain optimizations we could perform.

One scenario that we could consider is that we could write asynchronously to a datastore and use a local cache for reads. NOTE that this would cause issues if we have multiple sources writing to the database.

[arogut]

Are there any plans to create such support in near future?

[oxc]

A huge benefit of such locally cached sessions would be that transient variables are kept alive as long as the session does not leave one application instance.

[oxc]

A huge benefit of such locally cached sessions would be that transient variables are kept alive as long as the session does not leave one application instance.

I've tried to mitigate this in our application by wrapping the redis repository in a custom StickySessionRepository (untested). This has however none of the optimizations mentioned in the issue, it only allows access to transient fields.
In order to allow decent optimizations, I believe this would have to be integrated directly into repository implementations, or at least they would have to provide lastAccessedTime information in a resource-considerate manner.

[oxc]

I've created a more feature-complete proof-of-concept implementation of StickySessionRepository in oxc/spring-session-sticky.

It takes a remote repository as delegate, and provides

• local caching of sessions
• async writing of changes to the delegate session if configured
• revalidation of session freshness after a certain interval if configured

It currently provides an adapter for RedisIndexedSessionRepository. For more performant revalidation, this adapter accesses package private methods for RedisIndexedSessionRepository to directly access the lastAccessedDate of a session without deserializing all the attributes.

I would greatly appreciate:

• pointers on what changes are needed to get this integrated into spring-session
• code reviews
• help with testing (I have not deployed this on production yet)

Thanks!

[oxc]

We have been using this implementation on production now for several months without any noteworthy issues.

Is there any interest on getting this into spring-session?

[eleftherias]

Thanks @oxc.

Spring Session's approach of using clustered sessions is meant to remove the need for sticky sessions.

It does not prevent the use of sticky sessions, but also does not offer any performance optimizations when using them.

I am reluctant to add optimizations specifically for sticky sessions, since they are really an alternative solution to the same problem that Spring Session solves.

If Spring Session starts breaking sticky session functionality, or if many users think that this feature is necessary, we can take another look.