We want to move information about session state into the database for a couple of reasons:
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
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.
This comment was marked helpful 0 times.
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.
This comment was marked helpful 0 times.
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.
This comment was marked helpful 1 times.
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.
This comment was marked helpful 1 times.
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.
This comment was marked helpful 0 times.
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.
We want to move information about session state into the database for a couple of reasons:
This comment was marked helpful 0 times.
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.
This comment was marked helpful 0 times.
Another benefit of this is that this approach ensures that there is no restriction on the load balancing approach that the system can use.
This comment was marked helpful 1 times.
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 forX
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.This comment was marked helpful 1 times.
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.
This comment was marked helpful 0 times.
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.
This comment was marked helpful 0 times.