About Serialization

Serialization:
Serialization is the process of persisting the state of an object.
In Java serializing an object involves encoding its state in a structured way within a byte array. Once an object is serialized, the byte array can be manipulated in various ways; it can be written to a file, sent over a network or RMI, or persisted within a database as a BLOB.

The serialization process encodes enough information about the object type within the byte stream, allowing the original object to be easily recreated upon deserialization, at a later point in time.
Serialization and Deserialization is same as marshaling and unmarshaling in C/C++.

Where to keep serialized object:

Serialization is a highly versatile mechanism it should be addressed by storing the state in relational or object databases. It does not have transaction management and concurrency control. Nor does it provide any typical database features like indexed access, caching and a query language.

Serializing static variables:

Variables declared as static members are not considered part of the state of an object because they are shared by all instances of that class. Classes which need to preserve the value of static members during serialization should save and restore these values explicitly using private void readObject(ObjectInputStream) and private void writeObject(ObjectOutputStream).

Advantages and Disadvantages:

The advantages of serialization are:
It is easy to use and can be customized.
The serialized stream can be encrypted, authenticated and compressed, supporting the needs of secure Java computing.
Serialized classes can support coherent versioning and are flexible enough to allow gradual evolution of your application's object schema.
Serialization can also be used as a mechanism for exchanging objects between Java and C++ libraries, using third party vendor libraries within C++.
Many vital technologies that rely upon serialization, including RMI, JavaBeans and EJB.

Disadvantages:
It should ideally not be used with large-sized objects, as it offers significant overhead. Large objects also significantly increase the memory requirements of your application since the object input/output streams cache live references to all objects written to or read from the stream until the stream is closed or reset. Consequently, the garbage collection of these objects can be inordinately delayed.
Serializable interface does not offer fine-grained control over object access - although you can somewhat circumvent this issue by implementing the complex Externalizable interface, instead.
Since serialization does not offer any transaction control mechanisms, it is not suitable for use within applications needing concurrent access without making use of additional APIs.
Criteria for a class to be Serializable:
Have access to a no-argument constructor in its first non-serializable superclass
Identify non-serializable data members using the transient keyword or explicitly mark data members as serializable using the serialPersistentFields member.
My subclass implements Serializable but my superclass doesn't. Both subclass and superclass contain instance variables that need to be saved as part of the state of the subclass. Will serialization save the superclass fields for me?

When you serialize an object, the serialization mechanism works by chaining up the inheritance hierarchy, saving the sate of each Serializable superclass in turn. When serialization reaches the first non-serializable superclass, the serialization stops.

When deserializing, the state of this first non-serializable superclass is restored not from the stream, but by invoking that class' no-argument constructor. If the no-argument constructor is not adequate for your purposes, you must customize the serialization of your subclass with writeObject() and readObject() in order to write out and restore any information from the non-serializable superclass that you find necessary.

Externalizable instead of Serializable:

By implementing Externalizable yourself you can win performance at the cost of flexibility and extra code to maintain. If you implement Externalizable yourself you stream the data directly without the need for reflection which is used in the case of Serializable

Read and write serialized objects to and from a database:

If your RDBMS supports them, you can store serialized objects as BLOBs.
These are JDBC 2.0 features, but take a look at java.sql.Blob, ResultSet and PreparedStatement for more information.

Collections like Vector or a Hashtable:

Collections like Vector and Hashtable both implements Serializable and have been designed for serialization.
One thing to keep in mind is to watch out for is, that in order to serialize a collection like Vector or Hashtable, you must also be able to serialize all of the objects contained in these collections. Otherwise, the collection would not be able to be completely restored. Your program will throw a NotSerializableException unless all objects stored in the Vector or Hashtable are also serializable.

Other way to save the state of an object of a class which does not implement Serializable or Extenalizable

Write the value of each and every instance variable into the persistent storage. If there are 50 variables, you will have to store each of them individually. If some of the variables are object references, you will have to follow each reference and save the state of that object as well. You can do that, but it would be a proprietary solution and each class that wanted to read your object would also have to know all about your proprietary format.

Role of serialization in RMI:

RMI uses serialization as its basic and only mechanism for sending objects across a network.
If an object implements java.rmi.Remote, then the object's stub is serialized and sent to the client. If the object implements java.io.Serializable, then the object itself is serialized and sent.

Role of serialization in EJB:

A big part of EJB is that it is a framework for underlying RMI: remote method invocation. You're invoking methods remotely from one JVM space 'A' on objects which are in JVM space 'B' -- possibly running on another machine on the network.
To make this happen, all arguments of each method call must have their current state plucked out of JVM 'A' memory, flattened into a byte stream which can be sent over a network connection, and then deserialized for reincarnation on the other end in JVM 'B' where the actual method call takes place.
If the method has a return value, it is serialized up for streaming back to JVM 'A.' Thus the requirement that all EJB methods arguments and return values must be serializable. The easiest way to do this is to make sure all your classes implement java.io.Serializable.