Purpose of Serialization in webapplication
For your first and second question, have a look at this SO thread. Regarding your 3rd question, sessions.ser is a serialized session. However,
Yes, we need serialization whenever we need to persist objects in file system or send objects over the wire. You might think that in a web application we don't necessarily do that. But the server usually require a serializable thing in case it is needed in future when you switch to a clustered environment or want to pass your bean to a remote component, i.e. EJB component. Or you might want to store your bean into a session, for that reason your beans should be serializable.
Yes, for the same reason, stated above.
sessions.ser is a serialized session. Tomcat persisted it, so it can be recovered later. Now you had an idea that why we need serializable beans, because you might want to store bean objects to the session and Tomcat persist session to the file system, i.e. session.ser. So, your beans must implement Serializable so they can be persisted/recovered with the session.
By the way, the correctness of persisting and recovering of bean depends on the correct implementation of Serializable. For that I would recommend you to read the related topics in Effective Java.
1) It is an app server dependent feature but the Servlet Spec says that if the servlet container wants to support distributed environments (sharing sessions across instances) and the like that it must accept objects that implement Serializable and be able to migrate them. Tomcat also supports storing the session state across server restarts for session objects that are serializable. You can turn this feature of Tomcat on or off in the conf/context.xml file (see comments there).
2) It would only be neceesary for a form bean to be Serializable if a) it is session scoped and b) you are using either distributed sessions or a feature such as Tomcat uses to persist the session which requires it.
3) The sessions.ser file is the file containing the serialized objects from the session. Tomcat uses this to preserve them across restarts of the server if you have it configured to do so (see above). In general a .ser file is a serialized Java object, which is a binary representation of the state of the object.
Sessions (and all attributes added to it) need to be serializable if the container wants to store the session. This may have two reasons:
- the session has to be passed to an other node of a load balanced cluster
- sessions need to be swapped out because of low memory
Another possible reason is to pass request attributes from one webapp to another using cross context dispathing. Both webapps have different classloaders so simple cast would not work.
So your tomcat seems to write the session to a file using serialization. A form bean is typically also stored in the session, so yes, it has to be serializable.
And last, there may be much more reasons for serializable like in any other application. Caches may need it to swap out cache content (like ehcache can do). Any other data part may be serialized to be stored as blob in a database, ...