This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
As long as you not replicating or persisting the session data to support multiple clones, large sessions are ok. And of course assuming you have enough memory. If you are replicating/persisting, you are creating a lot of extra work for the server by having a large session.
Is it feasible to keep attribute(xml data) of size between 30-50KB in HttpSession in prodution environment.
Parsing this data and storing light weight objects would be a better choice. I do not know the context of your problem, so the last sentence may not apply. 50KB does not seem like much, but if multiple sessions store the same size, it will start to load the server memory when enough folks log in.
1. The RAM requirements for your webapp are going to be x + su * s, where "x" is everything else, "su" is the maximum number of concurrent session users, and "s" is the session object size itself. So, if this is an app with no more than 5 users, go for it. If it has 1500 users, you may want to reconsider.
2. The time required for serialization/deserialization of each session object is going to increase more or less linearly with the size of the object. So if lots of serial transformations are expected, be prepared.
Incidentally, I was (am) working with a web service where the SOAP API was defined by a company which is less talented than it is successful. It rammed several hundred KB worth of XML into my server code - which WAS, BTW stored as a session object in RAM. And blew it off.
Actually, the real pain wasn't so much the size of the session object, but of all the memory overhead while the serialization mechanism built a DOM out of it. Probably took 4x or more RAM to do that than it did to hold the final product.
Customer surveys are for companies who didn't pay proper attention to begin with.