Well, you could store the user session�s data inside a database and keep only the session identification.
But this approach has the downside of bad performance.
I have assumed that a flight list will not be too big, based on my actual experience. If the user was allowed to search all flights from Rio to SFO independent of date, then a big list will be created. But, if you read the requirements, that�s not the case.
If you are concerned about load distribution, consider that most
J2EE servers in the market support session migration.
And about your question, yes, this is correct. I have worked in the past with high demand Web Sites using HTTP session to store data. The session�s data are kept in the Web Tier, not the client. It is possible to store state in the client, embeeded in Hidden fields, but this is not the case.