State data can be stored either in memory or to a persistent data store:
In-memory storage uses a mirror-pair model where data is replicated between pairs of servers running in the cluster. In-memory storage offers better performance than persistent storage, but each client session has two points of failure (the originating server, and its mirror-pair twin). In-memory storage uses the EAServer message service to replicate data between servers in a mirror pair. See “Requirements for in-memory stateful failover” for more information.
Persistent storage uses a remote database to store component state. A component instance can failover to any other server in the cluster where the component is installed. Persistent storage requires a highly available database, otherwise the database itself can become a single point of failure.
The stateful failover architecture includes:
A storage component, which stores state data to a remote database or, for in-memory storage, calls the message service to replicate the data to the other server in the mirror pair. EAServer provides several storage components for database storage and for in-memory replication. You can also provide your own, custom implementation.
The component’s state datatype, which is an IDL structure or serializable class that allows transfer of state data from the stateful component instance to the storage component. For EJB stateful session beans, the state type is the implementation class (which is serialized to save the state).
The component’s state accessor methods, which the component or skeleton implements to interact with the storage component. When the client calls a business method, new state may be created in the component. After the business method returns, the storage component calls the get method to obtain the state data, passed as an instance of the state datatype. If the component fails over to another server, a new instance is created and the storage component calls the new instance’s set method, providing saved state data to initialize the new instance with the client’s session data.
For EJB stateful session beans, EAServer generates a skeleton with state accessor methods that get and set instance state using the standard EJB passivation and reactivation protocol. For components of other types, you must implement accessor methods and specify their names in component properties as described below
The server takes care of converting the specified state data type to and from a form suitable for persistent storage or in-memory replication. This feature is very powerful because any IDL datatype (or serializable Java class) can be used as the state type. In many cases, the most suitable state type is an IDL struct type, which can be created in the IDL editor (required when using C++ or COM components), or generated automatically from a PowerBuilder structure type by the PowerBuilder deployment process.
