Use Redis as a session store for Hybris Commerce

When running Hybris Commerce (or any web application for that matter) in cloud infrastructure, we need to cater for the fact that our application containers or VMs may fail/stop at any time. This needn’t be because of an error scenario; it can even happen when the infrastructure is scaled out or scaled down.

The traditional/default approach of maintaining sessions in the server’s memory with sticky sessions won’t be enough. Which is why it is one of the tenets of The Twelve Factors App.

Hybris Session Failover Support

To create a centralised session store, we looked at what Hybris Commerce offers out of the box. This is what we found:

HTTP Session Failover

The mechanism does use spring-session, but the backing store is the database which of course may not be the most performant solution.

We initially looked at how we can extend the same capability and use Redis for storage instead of the database because that seemed like the easiest way to accomplish what we need. But that ended up being a bit of a rabbit hole.

Spring Data Redis

We eventually settled on using spring-data-redis. Since Hybris Commerce already uses a lot of spring modules, using another community supported solution seemed like the best way forward.

We’ll look at how we add a session store to our storefront extension.

Adding the dependencies

First step we need to add relevant dependencies. Since we are currently using Hybris 6.7.x, the latest compatible versions of libraries we needed were:

• spring-data-commons-1.13.23.RELEASE.jar
• spring-data-keyvalue-1.2.23.RELEASE.jar
• spring-data-redis-1.8.23.RELEASE.jar
• jedis-2.9.0.jar

Hybris already packs spring-session, so we don’t need to add that again.

SessionStoreConfiguration

We need to create a spring configuration class to enable redis backed http sessions.

This configuration class needs a couple of things to work:

• It needs a ConfigurationCondition; SessionStoreCondition to evaluate to true

• And for the property spring.sessionstore.hostname to have the url to the redis server/cluster.

Now we need to add the configuration class to our extension’s spring context. Best practise for hybris extensions is to segregate beans by functionality in spring context xmls. So let’s create one for spring session:

Now import this into the main web-app-config.xml

Once all of this has been done, a new filter bean; springSessionRepositoryFilter will be available in the context. Add the filter to the storefrontFilterChain:

With these changes we have all the ground work to have our sessions stored centrally using a redis server/cluster. We’ve introduced two properties to configure it:

• spring.sessionstore.enabled
• spring.sessionstore.hostname

NO-OP SessionRepositoryFilter

When spring.sessionstore.enabled is set to false, our storefrontFilterChain still references springSessionRepositoryFilter which can prevent our application from starting up without errors. To workaround this, create a NO-OP SessionRepositoryFilter:

The filter depends on SessionStoreConditionNot which is the inverse of SessionStoreCondition:

Ensure Session is Serializable

Storing sessions in Redis using spring-session requires that sessions be serializable. Hybris Commerce does have some inbuilt capability to verify session serialization. Please check the documentation here:

Enable Session Serialization Checking

Enable session.replication.support

If you are relying on attributes in the JaloSession, you’ll need to set session.replication.support to true.

Hybris’s SessionFilter adds JaloSession as an attribute to the servlet container’s session. Every attribute added to session is serialised and saved into the session store.

But since JaloSession itself is a store for other attributes, mutations to JaloSession can’t automatically be persisted in the session store.

When session.replication.support is true, Hybris’s SessionFilter removes and adds the JaloSession attribute again to session after executing the filter chain so that any changes to JaloSession are persisted to the session store.

Watch out for cookie manipulation

This is probably not relevant to everyone who tries to use Redis to back session storage of their Hybris Commerce solution, but we had code that specifically rewrote the JSESSIONID cookie to the response. The problem was that the filter that performed this operation relied on session.getId() and expected it to be JSESSIONID. But once we add springSessionRepositoryFilter to the filter chain, session.getId() will return the id for the wrapped spring session object.