Question

When not to use CREATE SESSION ?

Answer 1

The problem with putting state in the session is that it means that requests from a specific user have to be tied to a specific server i.e. we have to use a sticky session/session affinity.

This reduces our ability to scale our system horizontally (scale out) i.e. by adding more servers to handle requests.

If, for example, we have a small amount of users (whose first request went to the same server) making a lot of requests (perhaps through AJAX calls) then we may quickly put one of our servers under load while the others are sitting there idle.

In addition we have increased complexity around our deployment process.

If we want to do an incremental deployment of a new version of our website across some of our servers then we need to ensure that we create a copy of any sessions on those servers and copy them to the ones we're not updating so that any users still on the system don't experience loss of data.

There are no doubts products which can allow us to do this more easily but it seems to me to be an unnecessary product in the first place since we can just design our application to not rely on the session.

As I understand it the web was designed to be stateless i.e. each request is independent and all the information is contained within that request and the idea of the session was only something which was added in later on.

How does the way we code change if we don't use the session?

One thing we've often used the session for on projects that I've worked on is to store the current state of a form that the user is filling in.

When they've completed the form then we would probably store some representation of what they've entered in a database.

If we don't use the session then we need to store this intermediate data somewhere and include a key to load it in the request.

On the project I'm working on at the moment we're storing that data in a database but then clearing out that data every other day since it's not needed once the user has completed the form.

An alternative perhaps could be to store it in a cache since in reality all we have is a key/value pair which we need to keep for a relatively short amount of time.

Advantages/disadvantages of this approach

The disadvantage of this approach is that we have to make more reads and writes to the database to deal with this temporary data.

Apart from the advantages I outlined initially, we are also more protected if a server handling a user's request goes down.

If we were using the session to store intermediate state then that information would be lost and they would have to start over.

In the approach we've using this isn't a problem and when the request is sent to another server we can still query the database and get whatever data the user had already saved.

As with most things there's a trade off to be made but in this case it seems a fair one to me.

Alternative approaches

I've come across some alternative approaches where we avoid using the session but don't store intermediate state in a database.

One way is to store that state in hidden fields on the form and another is to send it in the request parameters.

Neither of these approaches seem particularly clean to me and they give the user an easier way to change the intermediate data in ways that the form might not allow them to do.

Importance:

Because HTTP is stateless, in order to associate a request to any other request, you need a way to store user data between HTTP requests.

Cookies or URL parameters ( for ex. like http://example.com/myPage?asd=lol&boo=no ) are both suitable ways to transport data between 2 or more request. However they are not good in case you don't want that data to be readable/editable on client side.

The solution is to store that data server side, give it an "id", and let the client only know (and pass back at every http request) that id. There you go, sessions implemented. Or you can use the client as a convenient remote storage, but you would encrypt the data and keep the secret server-side.

Of course there are other aspects to consider, like you don't want people to hijack other's sessions, you want sessions to not last forever but to expire, and so on.

In your specific example, the user id (could be username or another unique ID in your user database) is stored in the session data, server-side, after successful identification. Then for every HTTP request you get from the client, the session id (given by the client) will point you to the correct session data (stored by the server) that contains the authenticated user id - that way your code will know what user it is talking to.

EXAMPLE:Cart on the server

On the server, isn’t that the same as storing a session on the server?

Yes and no. We can store the users cart on the server as long as we do it in a RESTful way we won’t hit any of the problems associated with user sessions. The problem with sessions is that we’re storing client state on the server, however if we don’t treat the clients cart as being part of their state and rather treat it as being part of the shop itself, then we can get around the problems with sessions.

Imagine a shop where rather than being self-service, there is a shopkeeper who upon being asked, goes and fetches the items you want and rings them up on the till. Now if we were to model that as our online shop we’d see that the client no longer has a basket as part of their state, the basket is part of the shop.

So how would this work? Looking at the interactions between the client and the server, it might look something like this:

Client

Show me your products.

Server

Here’s a list of all the products you can buy at this shop.

Client

Good, okay, I’d like to buy 1 of http://example.org/shop/product/X, please place it in my basket, my username is “JohnDoe” and my password is “secretPassword”.

Server

Okay, I’ve added 1 of http://example.org/shop/product/X into your basket, you can review your basket at http://example.org/shop/users/johndoe/basket

Client

I’d like to buy 1 of http://example.org/shop/product/Y as well, please place one in my basket, my username is “JohnDoe” and my password is “secretPassword”.

Server

Okay, I’ve added 1 of http://example.org/shop/product/Y into your basket as well, you can still review your basket at http://example.org/shop/users/johndoe/basket

Client

Actually I don’t want http://example.org/shop/product/X after all, please remove it from my cart, my username is “JohnDoe” and my password is “secretPassword”.

Server

Okay, I’ve removed http://example.org/shop/product/X from your basket, you can review your updated basket at http://example.org/shop/users/johndoe/basket

Client

Okay I’m done, ring ‘em up, my username is “JohnDoe” and my password is “secretPassword”.

Server

Should I charge that to your expense account?

The thing to notice about this conversation is that it is stateless, every action from the client is independent of any other. This means that at any time, the user can run off and do something else, come back a few days later and carry on. It also means they could get some other service to add things to their shopping basket easily.

Ain’t that just a session?

So how does this differ from storing the cart in a user session on the server? After all doesn’t the conversation above also apply no matter whether we’re storing the cart in a session or in a resource?

Firstly a users session is transitory, it’s there when the user is there, but will be cleaned up and lost once they leave, in our RESTful design the cart is as integral as a user account, so whatever means we use to store and process user accounts we use to store and process the users cart (so it might be a MySQL database cluster with Memcached in front of it).

Secondly we can grab hold of the users cart since it’s a resource that has a URL, so we can query and manipulate it at will, pass the URL to other services, etc.

The differences can seem very subtle, but it’s the subtleties that make the difference, since we’re explicitly creating and adjusting resources on the server all the problems of session handling disappear and are covered by our resource handling solution (our DB cluster for example).

Conclusion

Avoiding sessions is a bit of a purest stance, but it does lead to a more scalable and usable Web app. Keeping the clients state on the client is always a good idea, you can’t scale better than by utilising someone elses computer, of course depending on your application and the technologies you are using your mileage may vary.

If you do find you need to store transitory client data on the server, think about re-working that data or the way your app. works so that the data has meaning, give it a URL and turn it into a resource the user can manipulate.