Application Session Stores on CloudBees

Question

I'm trying to fully understand when/how to use CloudBees' notion of application session stores.

After reading that article, my understanding of them is that they provide a way to make multiple instances of your appserver share persistent session variables. That way, you can load balance between each server, and it doesn't matter which instance your user gets redirected to; each server instance has the same shared session states (for all users).

So first, if my understanding is incorrect or slightly misinformed, please begin by correcting me!

Assuming I am more or less correct, then I have the following questions:

1. How does this hurt performance or memory utilization? I would imagine that if each server has to share the same cached session data for all users, it would get kind of bulky and perhaps even pricy...
2. Is there a way to programmatically CRUD session states (i.e. flush the cache, inspect it with JMX, etc.)?
3. Can someone provide a concrete use case for this feature, just so I'm positive I "get it"?

Thanks in advance!

Answer 1

Session store let you replicate the HttpSession around the cluster, so that you can scale-out application load on multiple instances, without having to stick a user to a specific server (this is the other option you can use : configure sticky session)

By nature, serializing HttpSession data has some impacts on performance, but as it uses a memcache backend this is minimal. This also mostly depends on the amount and size of objects you store in user session. Also, please note this require you explicitly put object in HttpSession after any attribute change, even the object was retrieved from session - this is a general API issue with JavaEE clustering.

You can't programmatically query the session store (you could with the adequate memcache client code, but this doesn't make much sense)

Two concrete use cases

• application distributed on multiple nodes, with session distributed around the cluster, and without sticky session so that load is actually distributed for ALL user
• Application te be redeployed can't suffer user session to be lost, to ensure a continuous 0 downtime service. version N+1 application will then retrieve httpsession data from version N, need to be compatible from serialization point of view, but connected user won't notice the redeployment and version upgrade