I am designing a JSP/Servlet application and I would like to keep a fairly large amount of information in the session for convenience and performance reasons. My concern is that if I have a high volume of users I could run out of memory because of this. However, since session objects must be declared as Serializable, does this mean that if memory becomes low they will be temporarily copied to disk until needed again? If so, is this part of the specification or is it up to the particular Servlet container implementation? If it depends on the specific implementation, how does Tomcat handles this? Thanks.
Is this true? I could not find any such restriction in the Servlet 2.3 Specs. As far as I could tell, only applications marked <distributable> may require that session attributes are Serializable. And even then, it's only a requirement under certain conditions: Section 7.7.2 of the spec states "The servlet container may throw an IllegalArgumentException if an object is placed into the session that is not Serializable or for which specific support has not been made available. The IllegalArgumentException must be thrown for objects where the container cannot support the mechanism necessary for migration of a session storing them." ------------------ Miftah Khan - Sun Certified Programmer for the Java� 2 Platform - Sun Certified Web Component Developer for the Java� 2 Platform, Enterprise Edition
Because sessions are serializable, WebLogic 5.1 was able to recover from server crashes without losing session info (in my experience). But I would NOT assume that a given server would treat sessions a la virtual-memory unless the vendor has expressly guaranteed it. You might consider migrating some of the bulkier data to EJBs - they normally ARE cached objects and entity beans WILL be keep in persistend storage.
Customer surveys are for companies who didn't pay proper attention to begin with.
I'm willing to bet that a fair chunk of the information you want to bind to the session is in fact not specific to that session at all, and might be bound in the application scope instead. Of course this means that the code should be absolutely threadsafe. Also, your sessions might be way too large for a persistence mechanism to work efficiently anyway. Brown et al assert in Enterprise Java Programming with IBM Websphere that "performance studies have shown that the maximum size that an HttpSession can be before it takes too long to marshal and unmarshal into the database is somewhere between 2K and 4K". This is about session persistence for failover, not swapping, and no doubt dependent upon Websphere's implementation. But for other application servers the figure might not be wildly different. - Peter