Win a copy of Fixing your Scrum this week in the Agile forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Rob Spoor
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Tim Cooke
Saloon Keepers:
  • Tim Holloway
  • Piet Souris
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Frits Walraven
  • Himai Minh

Max. size of HttpSession attribute

 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

What could be the max. size of session attribute?
Is it feasible to keep attribute(xml data) of size between 30-50KB in HttpSession in prodution environment.

Thanks in advance.
Shiva
 
Ranch Hand
Posts: 88
Spring Tomcat Server Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It always comes down to how much resources you have on server jvm (RAM).
J2EE does not have any limit of session size.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Remember that your attribute will presumably exist for each session in the application. So if you put large objects in memory you will limit the amount of concurrent users your server can support. You also need to be mindful of aggressively releasing resources (i.e. short session timeouts, JavaScript to try to remove sessions on browser close and garbage collection tuning). That being said, 30-50KB is not a massive amount given the relative cheapness of memory these days.
 
author & internet detective
Posts: 40709
827
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 6663
5
MyEclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Saloon Keeper
Posts: 24168
165
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
... 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.
 
Deepak Bala
Bartender
Posts: 6663
5
MyEclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

while the serialization mechanism built a DOM out of it



 
Tim Holloway
Saloon Keeper
Posts: 24168
165
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Deepak Bala wrote:

while the serialization mechanism built a DOM out of it





The serialization mechanism in question was called "Apache Axis". Maybe Axis2 handles it better, but I haven't had time to convert.
 
Deepak Bala
Bartender
Posts: 6663
5
MyEclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:

Deepak Bala wrote:

while the serialization mechanism built a DOM out of it





The serialization mechanism in question was called "Apache Axis". Maybe Axis2 handles it better, but I haven't had time to convert.



If I understand correctly, your server side code calls a WS which uses "Apache Axis" ? Are you referring to the marshalling / unmarshalling of the XML (in)to java objects ?

Feel free to correct me if I misunderstood
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic