Integration Server 10.11 | Clustering Guide | An Overview of Clustering | Integration Server Session Objects for Stateful Clusters | Usage Notes for Session Storage
 
Usage Notes for Session Storage
*Only objects that are serializable can be successfully stored in the session when Integration Server is running in a cluster. That is, those objects must implement the java.io.Serializable interface or one of the com.wm.util.coder interfaces such as com.wm.util.coder.IDataCodable. In a cluster, a session is serialized to the shared session store. When the session is restored from the shared store to an Integration Server, the complete state of the session, including any application data that had been saved to it, is available. If the session contains objects that are not serializable, those objects are converted into strings that hold the objects' class names. The actual state of those objects is lost.
The requirement that these objects be serializable applies to the entire object graph, including the object placed into the session and every object it contains, no matter how deeply nested.
Although your production application can run in a cluster, you will be developing it on a stand-alone Integration Server (clustered development is not supported). It is important to be aware of the serializable requirement so that you do not encounter problems with your session data once you start to test in a cluster.
*The processing speed of a cluster is determined in large part by network I/O. Adding application data to the session state will increase the amount of I/O the cluster must perform, and make it operate more slowly. The addition of a single large or complex object to each session can have a noticeable effect on the overall throughput of a cluster.
If you are concerned that saving application data to the session might impact the performance of your Integration Server cluster, consider other ways of saving this data. If it does not have to persist across server restarts and does not have to be shared throughout the cluster, a simple Java collection such as a Vector or HashMap might be appropriate. If the data needs to survive server restarts but does not have to be shared throughout the cluster, writing it to the local file system is an option. If the data needs to be shared throughout the cluster, consider saving it in a database.
*Even though sessions are created and maintained in a distributed cache, each Integration Server keeps a portion of the cache locally. The local cache stores information relating to the sessions that are active on Integration Server as well as a list of nodes in the cluster. If you anticipate that your Integration Server sessions will use a large portion of the cache, you should increase the Maximum Elements In Memory or Maximum Off-Heap settings for each Integration Server in the cluster. For information about changing these settings, see Working with Caches.