# Supporting Serialization

When you build web services that use conversations, the conversation state is persisted between method invocations by serializing the web service instance to a database. Serialization is the technique through which Java objects may be written to a persistent store as a stream of bytes. When an object is serialized, methods are ignored but all member variables are serialized unless the member variable is marked transient. This means that all member variables of conversational web services must be serializable unless the variable is marked transient.

Note: Since Java controls used by a web service are represented as member variables in the web service, each Java control will also be serialized, meaning the Java control's member variables must also be serializable. The same is true for Java controls that are used, in turn, by Java controls. The WebLogic Workshop compiler will issue compiler errors if member variables are not serializable.

Note: In the case of Web Service controls, the state of the Web Service control will only be serialized of the target web service is conversational.

Note: Remember that a Java control is only a proxy for the resource it represents. Serialization of a control persists the state of the proxy, not the state of the resource itself.

During a conversation, a web service's state is serialized after each successful execution of:

- A method marked with a @common:operation annotation and marked with a @jws:conversation phase attribute of start or continue.
- A control callback handler.

Note that serialization will not occur for these if the method, callback, or callback handler throws an unhandled exception.

The requirement that member variables be serializable is typically easy to meet. For Java primitive types, serialization is supported by default. These types include byte, boolean, char, short, int, long, double, and float. Also, while classes in Java must implement the Serializable interface to be serializable, many of the Java classes representing common data types already do so. These types include those that are wrappers around the primitive types—such as Boolean, Long, Double, Integer, and so on—as well as String and StringBuffer. (When you are in doubt about whether a particular common class implements Serializable, check reference information for the class before using it.)

When you create your own classes for use in typing member variables, or when you handle classes created by others, you must take care to ensure that these classes implement the Serializable interface. Even so, this is typically easy to do because the interface contains no methods to implement—implementing the interface merely marks the class as supporting serialization. Your class code must simply import the package containing the interface and its declaration must be marked with the implements keyword, as follows:

    import java.io.Serializable;

    public class MyClass implements Serializable
    {...}

For more information on Java object serialization, please consult your favorite Java book.

## Conversations and Clusters

Clusters are not directly aware of conversations. Conversational state is stored in a database that is available from all servers in the cluster. The cluster handles a conversation continuing or finishing request in the following way: (1) the request gets routed to a cluster member, (2) the current conversational state is loaded from the database, (3) the operation is run, and (4) the conversational state is updated in the database. Subsequent conversational requests are handled this way each time, regardless of which server in the cluster handles the request.

The conversational state is stored in the database and is updated by conversational operations from whatever cluster member handles the request. Row-level locks on the database prevent the execution of multiple, simultaneous queries to the same conversation. The transactional capabilities of the database are used to insure that conversational state is consistent and durable.

To optimize performance, if the request continues a conversation and the conversational state hasn't changed, only the last-access-time field in the database is updated. This writes a Java.lang.long data type to the database, but avoids writing a BLOB.

Related Topics

Overview: Conversations

How Do I: Add Support for Conversations?