There are four main options for you :
1) Use sessions (bad idea IMO)
2) Persist the data in a database
3) Carry the data around, either on the URL, or in html <input type="hidden"/> tags.
4) Cookies
There are pros/cons for each approach :
1) Sessions are a bad idea for websites that need to be load-balanced, because a server needs to be 'sticky' - ie once a user has created a session on a server, they must stay there. In e-commerce, this is a really big no-no. There are solutions for this (such as Tomcat's clustering solution - but IMO this is too heavyweight and would introduce performance problems).
On the other hand, using sessions is extremely easy - but don't let that ease fool you. I personally dislike sessions these days - and wish we hadn't relied on them so much in the past.
2) Many people think that persisting your data in a database is too heavy - but it does get around the load-balancing problem. If you use pooling, the hit will not be too bad. This is probably my favourite mechanism right know, mainly because you know its going to be scalable. If you write a solution that is slick, you will be able to persist data (as a session in effect) as easily as using HttpSession objects.
3) Faily easy to do, but it looks messy, and is not secure at all - a "view source" or inspection of the URL will give away your data. However, if you are not carrying around much data, and that data is not sensitive, then its a possiblilty.
4) Store the data in a cookie - this is good if you don't have data that will be over 4k, and the client has cookies enabled. It also means your servers can be load-balanced. Good for not much data.
--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software