Re: Session Object Serailization

[Craig R. McClanahan]

Shahed Ali wrote:  Hi, Does tomcat seralize session objects ? 1. If it does, and I have non serializable objects like SQL Connections sitting in  my session, then    what should I do ? 2. If it does not, and I have a lot of sessions lying around, then will tomcat crash due to memory limitations ? ThanksShahed Currently, Tomcat 3.2 and 4.0 both support serializing session attributes across server restarts -- *if* your servlet attributes are serializable.  If they are not (such as JDBC connections), those attributes will disappear -- which means you should redesign your app to use connection pools or some other strategy instead of storing connections in sessions if you want to use this facility. The servlet 2.2 spec requires session attributes to be serializable, *if* you declare your app to be <distributable/> in the web app deployment descriptor.  Tomcat 4.0 enforces this requirement; 3.2 does not.  There are current discussions on TOMCAT-DEV around supporting distributable and/or persistent sessions in Tomcat 4.1 -- if you want your app to be able to take advantage of this when it becomes available, you should start conforming to the "session attributes must be serializable" restriction now.  NOTE -- some app server environments enforce more rigorous requirements outside the servlet spec; for example, they may require that session context attributes be Serializable as well. Tomcat will only "crash" (more properly, some web app will receive an OutOfMemoryException) if the sum total of all the objects in the JVMs memory space exceeds the available memory allocated to the JVM -- just like any Java app will.  You can do several things in your web app design to minimize the impact of this: * Shorten the lifetime of your sessions by setting the   inactive interval to something less than the default   (typically 30 minutes) * Call session.removeAttribute() to remove session   attributes you are through with. * Allocate more memory to your JVM than the default   (which is typically 16mb or 32mb).  This will require   setting a TOMCAT_OPTIONS environment variable that   is passed to the JVM in the startup script.  Of course,   your server should have enough physical memory   available to avoid swapping, or you are not going to   like the performance impact. Craig McClanahan