Previous | Next --- Slide 28 of 59
Back to Lecture Thumbnails
rokhinip

We want to move information about session state into the database for a couple of reasons:

  1. It allows the web server itself to be generic and so, we get an additional level of abstraction that separates the actual data from the computation/work that is being done in the web server itself
  2. Our web servers now don't need an internal database/infrastructure of any kind in order to keep track of session information. Presumably, when we had the session information stored on the web server - as in the previous slide - we had a limit on the amount of session state information we can keep track of. This is now, no longer a concern.
mofarrel

Having the session state stored independently from the workers allows the load balancer to map different requests from the same person to different workers. This is because all the different workers will be able to access that persons session state.

shabnam

Another benefit of this is that this approach ensures that there is no restriction on the load balancing approach that the system can use.

idl

Elaborating on what @mofarrel said, if we stored session state in each worker, if the worker with session ID X was very busy servicing a large request for example, and another request for X comes in, assuming there is just 1 worker per session ID, that request would probably have to wait. Storing the state independently of the workers would let the load balancer distribute that work to other workers that might be idle at that time.

jinghuan

For web applications that has multiple databases storing information about each client, session ID can also tell web process which database to look for this person's information.

DunkMaster

This model is also a more reliable scheme than the one in the last slide. Now if a worker went down for some reason, the load balancer could assign another worker to the user instead of creating a brand new session.