What is the key advantage (regarding scalability) of the cookie + cache mechanism in Play 2.0 compared to Java EE HttpSession?

Question

I understand that we don't like to maintain session state on server for scalability reasons in general, but I just don't see why the approach taken by Play 2.0 is said to be better than the old school HttpSession.

A major difference I see is the fact, that the HttpSession implementation is provided by the container, and hence scaling capabilities with HttpSession depends on it.

Answer 1

There are a number of advantages with this. In essence, the session model in Play promotes a share nothing architecture. This means that each action you execute, which if you follow the pattern as Play promotes, is a RESTful request, the execution of the action is entirely self contained. This means that each request can be unit tested individually, and your application built up as a set of discrete functions.

The principle here, is that the less coupling between each action, and the less conversational state that is being handled by a fat session, the cleaner and more robust your code becomes.

As a side effect, you also have the easy scaling through adding more nodes horizontally, which is usually cheaper than vertical scaling, and less complex and risky than sticky sessions.

Answer 2

Using a container managed session (and its encapsulated state) means when you want to scale horizontally, the systems involved will also have to make sure they replicate this state because your application will not work without it. A client that uses your application is effectively bound to the particular node the user happens to be directed to.

In contrast; when your application maintains no real session state at any point (as your Play application should) it's very easy to scale horizontally: just add more nodes that run the application and make sure that the front-end HTTP server knows about the new nodes. No fancy algorithms and "enterprise platforms" to replicate and maintain sessions across all nodes.

Answer 3

No, it is actually a little more complicated than that. Play actually pushes a stateless application architecture. Meaning, you are not storing any data in the session. Nothing, except the credentials may to be stored.

First rule : Session storage is deported to the database. Instead of fetching data from the session, get it from the database. Scalability is way easier for databases than JVM applications.

Second rule : Nothing is stored other then the credentials. Meaning, you will have to transmit information otherwise for conversationnel states. There are two mains ways of doing this. Using hidden fields, which in my opinion is not the best way. Secondly use absolute URLs. Create a URL containing ids, searches and other.