How session work and how the Container know who the client is

How session work

1.when Diane selects "Dark" and hits the submit button.The Container sends the request to a new thread of the BeerApp servlet.The BeerApp thread finds the session associated with Diane, and stores her choice ("Dark")in the session as an attribute.

2.The servlet runs its business logic (including calls to the model) and returns a response.

3.When Diane selects another option and hits the submit button.The Container sends the request to a new thread of the BeerApp servlet.The BeerApp thread finds the session associated with Diane,and stores her new choice in the session as an attribute(same client,same servlet,Different request,Different thread,Same session)

4.The servlet runs its business logic (including calls to the model) and returns a response.

5.Meanwhile ,another client goes to beer site...
Diane's session is still active ,but meanwhile Terri selects "Pale" and hits the submit button. The Container sends Terri's request to a new thread of the BeerApp servlet.The BeerApp thread starts a new session for Terri,and calls setAttribute() to 
store her choice("pale")(Different client,Same servlet,Different request,Different thread，Different session)

how  the Container know who the client is

The HTTP protocol uses stateless connections.The client browser makes a connection
to the server,sends the request,gets the response,and closes the connection.In other words,the connection exists for only a single request/response.Because the connections don't persist ,the Container doesn't recognize that the client making a second request is the same client from a previous request.As far as the Container's concerned,each request is from a new client.

so the client needs a unique session ID.The idea is simple:on the client's first request,the Container generates a unique session ID and gives it back to the client with the response.The client sends back the session ID with each subsequent request.The Container sees the ID ,finds the matching session, and associates the session with the request.

Somehow,the Container has to get the session ID to the client as part of the response ,and the client has to send back the session ID as part of the request.The simplest and most common way to exchange the info is through cookies.

You do have to tell the Container that you want to create or use a session,but the  Container takes care of generating the session ID,creating a new Cookie object，stuffing the session ID into the cookie,and setting the cookie as part of the response.And on subsequent requests ,the Container gets the session ID from a cookie in the request,matches the session ID with an existing session,and associates that session with the current request.

Sending a session cookie in the RESPONSE:
HttpSession session = request.getSession();/*This method does more than just create a session,but the first time you invoke it on the request ,it will cause a cookie to be sent with the response.Now,There's still no guarantee the client will accept the cookie...but we're getting ahead of ourselves.
The container takes care of making the new HttpSession object,generating the unique session ID,making the new Cookie object,associating the session ID with the cookie,setting the Cookie into the response ,all by itself.*/

Getting the session ID from the REQUEST:
HttpSession session = request.getSession();/*The method for getting a session ID cookie(and matching it with an existing session) is the same as SENDING a session ID cookie.You never actually SEE the session ID yourself(although you can ask the session to give it to you)*/

It works like this:
IF(the request includes a session ID cookie)
   finds the session matching that ID
ELSE IF (there is no session ID cookie OR there is no current session matching the session ID)
    create a new session.

All the cookie work happens behind the scenes.