In my application, I create and save a HashMap in session in first servlet and use it in the next servlet. First of all, is it a good idea to store a hashmap in session?
Maintaining a HashMap in the session context to persist data between requests is a common thing to do. You'll need to determine whether this approach is wise in your application given the size of the HashMap. If it's particularly large, remember that you may get one per user which may cause memory problems on your server at busy times. Only you know how much memory you have available, the maximum number of concurrent users you expect to support and the typical size of your HashMap.
Secondly, when I use back button in my application to go back and forth, would creating hashmaps everytime when I go back to the first servlet pose a memory constraint ?
If you're holding the HashMap in the session you only need to create it once. After that you just maintain it. If you don't use the session context but use request scope instead then any Hashmaps you create will be eligible for garbage collection once the response is generated. So no cumulative memory problems, no. Obviously you need to consider the time taken to create a new Hashmap each time versus maintaining a single Map in the session. If the Hashmap is small the difference is likely to be imperceptible.
Third of all, how do I remove a hashmap ? HashMap something = null; gave me a NULL pointer exception. Appreciate somebody's help.
Setting "something" to null makes the HashMap that "something" previously referred to eligible for GC. However, if you later try to access properties or methods on "something" in your code you'll get a NullPointerException. I mean, why would you remove the HashMap if you're then going to try and use it? To remove an attribute from the session context use (say) request.getSession().removeAttribute("myHashMap") [Note: this is the same as setAttribute("myHashMap", null)]. In request scope just leave it to the garbage collector. It'll clean up your objects once they're out of scope.
Hope that helps.
You don't need to worry. If you call session.setAttribute() with the same attribute name the new object replaces the old object and the old object becomes eligible for GC (as it no longer has a reference). The GC will do the work for you.
Have I understood your concern correctly?
Appreciate your help.
Consuequently the following three code snippets behave identically:
In each case removing an attribute when you're about to replace it is simply a waste of time. The "something" object becomes available for GC as soon as the second call is made (provided that there are no other references to it). Note that I say "becomes available for GC", not is GCed. You can't force the garbage collector to run ever. You can suggest that it might like to run (e.g. System.gc() - rarely necessary) but ultimately it makes its own mind up.
All this stuff's in the API docs by the way. you should have a read some time.
[ September 11, 2004: Message edited by: Julian Kennedy ]