Storing the state can be done in two places. One place, which we will first do in our code, is the client. When the program creates a new guess, it adds it to the table and sends an HTML page that contains not only the new guess but also all the previous guesses and the full and partial match values that the user gave for each of the rows. To send the data to the server, the values are stored in the fields of a form. When the form is submitted, the browser gathers the information in the fields, creates an encoded string from the content of the fields, and puts the content into the body of a POST request.

The other possibility for storing the actual state is in the server. The server can store the state of the game, and it can reconstruct the structure when it creates a new guess. The problem in this case is knowing which game to use. The server can and should store many games, one for each user, and users may use the application concurrently. It does not necessarily mean strong concurrency in the same meaning as we examined in the previous chapter.

Even if the users are not served at the same time in multiple threads, there can be games that are active. Imagine cnn.com telling you that you cannot read the news at the moment because somebody else is reading it. There can be multiple users playing multiple games, and while serving an HTTP request, we should know which user we are serving.

Servlets maintain sessions that can be used for this purpose as we will see in the next section.