Session Persistence in Cloud Foundry

Lets start from the basics:

1. By default, the Tomcat instance is configured to store all Sessions and their data in memory. Under certain circumstances it my be appropriate to persist the Sessions and their data to a repository.

2. The Cloud Foundry Go Router maintains session affinity. So users will keep hitting their session in the same container. Furthermore when the user logs out or his session expires he will be placed on a different container and a new session will start. If for some reason the container that contains the session dies then the user gets kicked out a new session begins on a different container if session persistence is not configured. The following blog post from James Bayer is a good intro to CF session persistence. 

There are a couple of issues relating to the update of the _vcap_id cookie when a  new session is created. Please ensure that your CF release has the following fixes ... 

1. cloudfoundry/gorouter #76: Sticky Sessions lost on App Failure
2. After app instances are recreated every request round robins to a different app instance 

3. If the session contains state of the user that cannot be rebuilt in a stateless fashion then I recommend session persistence using some kind of database like (Postgres) or a NoSQL store (like Redis).

4. The java-buildpack already has in-built support for session persistence with Redis. To enable Redis-based session replication, simply bind a Redis service containing a name, label, or tag that has session-replication as a substring. see

5. Another option you have is to use Spring Session project that implements session facade across app servers and protocol tiers like REST and WebSocket.

Sticky sessions are an optimization and not a guarantee; however you should be able to rely on CF pulling out the right session content if all the app instances are bound to a session persistence service.