Why and how is serialization used in Java web applications?

Question

I\'ve been working on a Java web application where the framework insists that everything is Serializable. I assume that this isn\'t specific to the framework but to web app

Answer 1

Serialization is useful in any application environment, not just web applications.

One major use for serialization is for transport. You want to copy or move an object to a remote computer, say a UserProfile. You can serialize the UserProfile, send the serialized data (typically XML) and deserialize it to a new object on the receiving end, at which point it can be manipulated as though it were the original object.

Another use is saving state. You may have a game and you want to save the exact state of a game board. You can serialize the Board object which can subsequently be told to serialize each of its Tiles.

Answer 2

Depending on the web framework, objects in the session might be persisted to disk by using serialization.

Answer 3

The typical issue is that during replication, or server shutdown, the internal HTTP Sessions are "Serialized" out to a persistent store so they can be recovered or shared.

Serialization is saving the state of an Object, and being able to reconstitute that state at a later time.

Answer 4

It's not strictly necessary for most apps, but can help performance in two ways:

• User sessions can be serialized to disk between requests. When the time between requests from the same user is much longer than the time it takes to process a request, this can drastically reduce memory usage of the server and enable you to serve far more users.
• If you use load balancing to spread requests over multiple servers, you either need to ensure that all requests by the same user are always served by the same machine (which reduces the flexibility of the load balancer) or you need to be able to move session data between servers via serialization.

Answer 5

If you are using Enterprise Java Beans (EJBs), and have a Stateless Session Bean API, then each SSB instance runs in one thread on one Java Virtual Machine, and its clients run in different threads, and, in general, in different JVMs on different computers. Because you can't pass a reference to a Java object from one JVM to another, the object needs to be serialized into a string, sent over to the other JVM, and then deserialized back into an object. This serialization/deserialization happens to both the arguments coming in and the return value going out.

If you're using the Java Message Service, the objects you send in each message get serialized into a string, persisted into a database, and then get deserialized by the message receiver at some other time and place.

And, as Will Hartung points out, HTTP Session objects in general are shared across JVMs. If you have a cluster of Glassfish Java EE application servers running an ecommerce application, each customer's requests are load-balanced to any available server, and that server must be able to look up the customer's session state (customer name, shopping cart, etc.). It can only get this via serialization. Session state may also be written to disk (eg, a database) for safety.