State Management

An XLANG Scheduler Engine maintains the execution and messaging state of a schedule instance. This state must be correctly restored across system failures, in the presence of transactions, or when schedules are rehydrated. When a system recovers from a failure, the state of all the running schedules must be restored to some known point. If a transaction fails, the schedule must discard the changes caused by the failed transaction and restore the state prior to that transaction before continuing. When a schedule instance is dehydrated, the bulk of its state is saved to a database, with only some vestigial elements needed to detect any events that might trigger rehydration. Hence, state management is an important function of the XLANG Scheduler Engine.

If COM components are used in the schedule, then, clearly, the engine must know how the components themselves manage their state. This is not an issue for messaging services, which have their own persistence mechanisms and transport messages asynchronously—the schedule merely “fires and forgets” the message.

For a COM component, you can specify one of three options for how it handles state. The wizard used to set these options is described later in the section “COM Component Binding Wizard.” The three options are

• Holds no state

• Holds state, but cannot persist it

• Holds state and can be asked to persist state on demand

Clearly, the first option where the component has no state to restore makes life easy for the engine. The XLANG schedules can be dehydrated or checkpointed prior to a transaction, without concern about how to deal with the internal state of the components. In this case, on restart, the engine can just discard the old component, create a brand-new component when the schedule next needs it, and use the new component to make method calls without concern for the component's internal computational state. This means that the instance of the component called may or may not be the one previously referenced in the schedule. If you passed an interface of this component to an application outside the schedule, that interface could be invalid some time later! However, not all is lost, at least within the schedule instance; the engine ensures that the references are updated when the schedule is rehydrated.

The second option, holding state but not being able to persist it, is not something you should aim for, if avoidable. This option provides for situations when you have no choice but to request the XLANG Scheduler Engine to try and hang on to the component (and its internal state). If the component is destroyed, its internal state goes with it. You may need to resort to this option—for example, when the component is communicating with legacy devices and the alternative of persisting its internal volatile state is unrealistic or impossible. In these situations, the XLANG Scheduler Engine keeps the component instance running. There is no automatic recovery available if the process hosting the component should die due to system failures.

The third option provides the more generalized solution. The XLANG Scheduler Engine can ask the component to checkpoint its state at any specific point in the process flow, or prior to dehydration. When checkpointed, the engine destroys the component object. The objects are re-created when necessary and asked to restore their saved state. The COM interfaces used for saving and restoring state are IPersistStream and IPersistStreamInit. If an object doesn't support both interfaces, it can not maintain state.

In Visual Basic, you implement these interfaces by setting class attributes to support persistence. When the class attribute is changed to Persistable, three new events are added to the class. These are InitProperties, ReadProperties, and WriteProperties. You must provide the proper implementation for these events.

Script components cannot implement the persistence interfaces, and hence you cannot specify the state options for such components.

The third option (and the first option) provides a scalable and robust solution. Note that state management is not an issue for messaging at all. The messaging systems provide their own persistence guarantees, the applications merely “fire and forget” messages.

We next look at how transactions are supported in the schedule.