... Or, just to say it all yet another way.
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.