Persistence Points in Orchestration

|  Posted: May 16, 2006  |  Categories: General Technical

The orchestration engine persists the entire state of a running orchestration instance at various points, so that the instance can later be completely restored in memory.

The state includes
1. The internal state of the engine, including its current progress.
2. The state of any .NET components that maintain state information and are being used by the orchestration.
3. Message and variable values.

Persistence Points

The orchestration engine saves the state of a running orchestration instance at various points. If it needs to rehydrate the orchestration instance, start up from a controlled shutdown, or recover from an unexpected shutdown, it will run the orchestration instance from the last persistence point, as though nothing else had occurred. For example, if a message is received but there is an unexpected shutdown before state can be saved, the engine will not record that it has received the message, and will receive it again upon restarting. The engine will save the state in the following circumstances:

1. The end of a transactional scope is reached.
The engine saves state at the end of a transactional scope so that the point at which the orchestration should resume is defined unambiguously, and so that compensation can be carried out correctly if necessary.

The orchestration will continue to run from the end of the scope if persistence was successful; otherwise, the appropriate exception handler will be invoked.

If the scope is transactional and atomic, the engine will save state within that scope.

If the scope is transactional and long-running, the engine will generate a new transaction and persist the complete state of the runtime.

2. A debugging breakpoint is reached.

3. A message is sent. The only exception to this is when a message is sent from within an atomic transaction scope.

4. The orchestration starts another orchestration asynchronously, as with the Start Orchestration shape.

5. The orchestration instance is suspended.

6. The system shuts down under controlled conditions. Note that this does not include abnormal termination; in that case, when the engine next runs, it will resume the orchestration instance from the last persistence point that occurred before the shutdown.

7. The engine determines that the instance should be dehydrated.

8.The orchestration instance is finished.

Serialization

All object instances that your orchestration refers to directly or indirectly (as through other objects) must be serializable for your orchestration state to be persisted. There are two exceptions:

1. You can have a nonserializable object declared inside an atomic transaction. You can do this because atomic scopes do not contain persistence points.
2. System.Xml.XmlDocument is not a serializable class; it is handled as a special case and can be used anywhere.

Caution In order for a .NET object to be persisted, it must be marked as serializable.

COM Objects

COM objects cannot be persisted using standard .NET serialization procedures. If you want to call a COM object outside of an atomic transaction, you must wrap the COM object in a .NET object that is .NET serializable and knows how to persist and restore the state of the COM object.

Author: Saravana Kumar

Saravana Kumar is the Founder and CTO of BizTalk360, an enterprise software that acts as an all-in-one solution for better administration, operation, support and monitoring of Microsoft BizTalk Server environments.

One Platform Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

One Platform - Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

One Platform - Operations, Monitoring and Analytics Software
ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

Back to Top