Purpose of Serialization in webapplication

1. Where is the usage of serialization 开发者_开发问答in a webapplication.

2. Is it necessary that a form bean is serializable.

3. In tomcat what is the usage of sessions.ser file..

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.

For your first and second question, have a look at this SO thread. Regarding your 3rd question, sessions.ser is a serialized session. However,

1. 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.

2. Yes, for the same reason, stated above.

3. 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.

Sessions (and all attributes added to it) need to be serializable if the container wants to store the session. This may have two reasons:

1. the session has to be passed to an other node of a load balanced cluster
2. 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, ...

Wow, lot of questions without a lot of context.

For your #1 I will assume you're talking about serialization that in which you allude in your other points about Java's serialization, not serialization vs. parallelism. If so, many web apps will serialize or save the state of objects to keep it durable. That durability can be used across HTTP requests (as in session management), for longer-term storage of information, or in order to send across a "network" in terms of ensuring that all parties get a copy of said information.

One must ask oneself in HTTP if that is indeed a good idea as by design and scale stateless is "good" and if one has a backing store such as a DB why the DB isn't doing the work. The form bean I would guess is used in this nature as servlets will pass around the form information as descrbied.

1. A pretty good description from wikipedia:

   Serialization has a number of advantages. It provides:

   • a method of persisting objects which is more convenient than writing their properties to a text file on disk, and re-assembling them by reading this back in.
   • a method of issuing remote procedure calls, e.g., as in SOAP
   • a method for distributing objects, especially in software componentry
     such as COM, CORBA, etc.
   • a method for detecting changes in time-varying data.

   A real world (simple) example: Say you create a User instance in java. Now you want to display this object in a web browser using javascript. One option is to serialize the object in such a way that javascript can deserialize the object (using a representation that both java and javascript can understand) and display it.

2. It depends on what you need to do with the form bean as to whether it should be serialized or not.
3. Tomcat Manager App is a web application that helps you deploy and manage other web applications to tomcat. I'm not a tomcat expert, but I think The Tomcat Manager tries to remember information about the sessions created by the web applications that it is managing. It needs to remember this info even when the tomcat process is restarted. So, Tomcat Manager creates a file named "Session.ser" which is a serialized representation of the information that it needs to remember about all the managed applications' sessions.