Redis-based session clustering

The setup had multiple WAS nodes, but each one held its own sessions independently. Restarting even a single node logged out every user pinned to it, and any form they were filling out was lost along with it. JEUS does offer session clustering, but only in the Enterprise license — our environment was Standard, so there was no official path to fix it.

• Restarts wiped out logins and form input

  Users routinely lost what they were typing with a single refresh

• Zero-downtime deploys were impossible

  Either defer releases to protect sessions, or accept session drops to ship — a constant trade-off

• No licensing path to a fix

  Session clustering ships only with JEUS Enterprise; unavailable on Standard

A license upgrade would have been expensive, so instead I moved sessions out of the application and into an external store. Spring Session integrates with Redis out of the box, so no application code had to change — only configuration. And because Redis responds in milliseconds, I expected almost no user-facing impact.

1. 01

   Stand up Redis

   I ran Redis 7.4 in a container on a shared Docker host, wiring up a password, a persistent volume, and an auto-restart policy. The host, port, and password used by the application were extracted into a separate properties file.

   install-redis.sh

   bash

   # Install Redis (7.4.2)
   docker pull redis:7.4.2
    
   # Run the container
   docker run -d \
     --name redis \
     --restart unless-stopped \
     -p 6379:6379 \
     -v /data/redis:/data \
     redis:7.4.2 redis-server --requirepass "your-password"

   redis.properties

   properties

   # redis.properties
   redis.host     = your.redis.host
   redis.port     = 6379
   redis.password = your-password
   redis.database = 0

2. 02

   Add Spring Session dependencies

   I added Spring Session, Spring Data Redis, and Lettuce to the eGovFrame project's pom.xml. This is the groundwork for delegating servlet sessions to an external store.

   pom.xml

   xml

   <!-- pom.xml - Spring Session + Redis dependencies -->
   <dependency>
       <groupId>org.springframework.session</groupId>
       <artifactId>spring-session-data-redis</artifactId>
       <version>2.7.0</version>
   </dependency>
   <dependency>
       <groupId>org.springframework.data</groupId>
       <artifactId>spring-data-redis</artifactId>
       <version>2.7.0</version>
   </dependency>
   <dependency>
       <groupId>io.lettuce</groupId>
       <artifactId>lettuce-core</artifactId>
       <version>6.2.0.RELEASE</version>
   </dependency>

3. 03

   Wire up the Redis connection and session mapping

   In context-redis.xml I declared a LettuceConnectionFactory and RedisHttpSessionConfiguration. That maps the HTTP session to Redis automatically, so no application code had to change.

   context-redis.xml

   xml

   <!-- context-redis.xml - Redis connection, serialization, and session config -->
   <bean id="redisConnectionFactory"
         class="org.springframework.data.redis.connection.lettuce.LettuceConnectionFactory">
       <property name="hostName" value="${redis.host}"/>
       <property name="port"     value="${redis.port}"/>
       <property name="password" value="${redis.password}"/>
       <property name="database" value="${redis.database}"/>
   </bean>
    
   <bean class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
       <property name="maxInactiveIntervalInSeconds" value="1800"/>
   </bean>

• Zero-downtime deploys unlocked

  Rolling WAS restarts now preserve sessions. Hotfixes and test rollouts can ship without taking the service offline.

• Login drops eliminated

  Under failover, redeploys, and long-running operation, users no longer get kicked out or lose form input.

• Worked around the license ceiling with an external store

  I delivered session clustering without buying the higher license tier — a firsthand lesson that platform constraints can often be solved at the architecture layer.

• Next time, verify compatibility up front

  Because the eGovFrame version was older, validating Spring Session and Redis compatibility took more time than expected. Going forward, I will pin down compatibility before I start.