i understood your problem but why you are do such a hardwork to do the tracking by yourself ,you can use a third party filter to track users the tool which is commonly used and take control of all your memory space problms is CLICKSTREAM you can know more abt this on the site www.opensymphony.com or directly go to this link
if you weren't meant to place objects into the session: 1) it would be a pretty useless object (that is, the session object would be stupid) 2) you wouldn't have a method like session.setAttribute()
If your application is anything beyond a simple form submission, or set of forms, then your application needs state. State in a web-app, state that belongs only to a certain user... that is what Session is *for*.
You could use a database. The only thing on the Session object would be the userid and perhaps a few other well chose id's. This would limit the data in the session. With these keys, you'd then retrieve the state you needed from the database. This also has problems. (how do you clean up abandoned sessions? what if the db become unavailable?)
The 'best practice' I've always heard about is to minimize your usage of Session, because of the memory requirements, etc. However, I'm not 100% convinced you in particular should be worried. 10MB (for all your users) seems laughably small to me. And even if your usage peaks or expands, as William points out, most decent servers can handle memory management. If not, you can cluster your app server, add memory, etc. Might your memory "run out?". Of course it will, if you don't have enough. So add more.
Unless you're doing some humongeous PeopleSoft-type web-app where the state data grows to like 20MB **per user**, I think you're safe to use Session. [ June 26, 2004: Message edited by: Mike Curwen ]
Author and all-around good cowpoke
Joined: Mar 22, 2000
William, is it advisable to use sessions to store objects in it in a j2ee appln? if there are 1000 such users per hour or per day, won't the memory be full?
The whole idea of sessions is to store user specific data between requests so as to facilitate a rapid response as the user goes through some complex process such a adding stuff to a shopping cart. However it is not good practice to throw everything into a session - you have to think carefully about which objects have data specific to a particular user and which do not. To continue with the shopping cart example, you would not store a String representation of a catalog page in a user's session, but you might store a String code indicating the page the user is currently looking at. You would not store a reference to a big object representing the catalog because if the session gets serialized, the whole catalog would be written out. The reference to a catalog object could be stored in the ServletContext and shared by all servlets in that "web application". Remember that the servlet engine will clean up session memory when the session timeout expires, also if you can get your user to "log out" - you can invalidate the session in your own code.