Kim’s design won’t work unless he can keep track of everything the client has already said during the conversation, not just the answer in the current request. He needs the servlet to get the request parameters representing the client’s choices, and save it somewhere. Each time the client answers a question, the advice engine uses all of that client’s previous answers to come up with either another question to ask, or a final recommendation.

What are some options?

Use a stateful session enterprise javabean

Sure, he could do that. He could have his servlet become a client to a stateful session bean, and each time a request comes in he could locate that client’s stateful bean. There are a lot of little issues to work out, but yes, you can certainly use a stateful session bean to store conversational state.

But that’s way too much overhead (overkill) for this app! Besides, Kim’s hosting provider doesn’t have a full J2EE server with an EJB Container. He’s got Tomcat (a web Container) and that’s it.

Use a database

This would work too. His hosting provider does allow access to MySQL, so he could do it. He could write the client’s data to a database... but this is nearly as much of a runtime performance hit as an enterprise bean would be, possibly more. And way more than he needs.

Use an HttpSession

But you already knew that. We can use an HttpSession object to hold the conversational state across multiple requests. In other words, for an entire session with that client.

(Actually, Kim would still have to use an HttpSession even if he did choose another option such as a database or session bean, because if the client is a web browser, Kim still needs to match a specific client with a specific database key or session bean ID, and as you’ll see in this chapter, the HttpSession takes care of that identification.)