Microsoft KB Archive/926627

= BizTalk Server 2004 documentation that describes persistence and system shutdown information contains some inconsistences =

Article ID: 926627

Article Last Modified on 3/16/2007

-

APPLIES TO


 * Microsoft BizTalk Server 2004 Developer Edition
 * Microsoft BizTalk Server 2004 Enterprise Edition
 * Microsoft BizTalk Server 2004 Partner Edition
 * Microsoft BizTalk Server 2004 Standard Edition

-



INTRODUCTION
The Microsoft BizTalk Server 2004 documentation that describes persistence and system shutdown information in BizTalk 2004 contains some inconsistencies. The information that is located on the following Microsoft Web pages is incorrect:

http://msdn2.microsoft.com/en-us/library/ms946272.aspx

http://msdn2.microsoft.com/en-us/library/ms963306.aspx

For the correct persistence and system shutdown information for BizTalk 2004, see the &quot;MoreInformation&quot; section.



MORE INFORMATION
The following information about BizTalk 2004 persistence and system shutdown behavior is correct.

Orchestration engine
The orchestration engine saves the whole state of a running orchestration instance to persistent storage at various points. Therefore, the instance can later be completely restored in memory.

The state of a running orchestration instance includes:
 * The internal state of the engine. This includes the engine's current progress.
 * The state of any Microsoft .NET components that maintain state information and that are being used by the orchestration.
 * Message and variable values.

Persistence points
The orchestration engine saves the state of a running orchestration instance at various points. If the engine must rehydrate the orchestration instance, start from a controlled shutdown, or recover from an unexpected shutdown, the engine runs the orchestration instance from the last persistence point, as if nothing else had occurred. For example, if a message is received and if an unexpected shutdown occurs before the state can be saved, the engine does not record that it has received the message. Instead, the engines receives the message again after it restarts. The engine saves the state of an orchestration in the following circumstances:
 * The end of a transactional scope is reached.
 * The engine saves the state at the end of a transactional scope. Therefore, the point at which the orchestration resumes is defined unambiguously. Compensation can be performed correctly, if it is necessary.
 * The engine saves the state at the end of a transactional scope. Therefore, the point at which the orchestration resumes is defined unambiguously. Compensation can be performed correctly, if it is necessary.
 * The orchestration continues to run from the end of the scope if persistence was successful. Otherwise, the appropriate exception handler is invoked.
 * If the scope is transactional and atomic, the engine saves the state at the end of the atomic scope when the scope commits.
 * If the scope is transactional and long-running, the engine generates a new transaction and persists the complete state of the runtime when the scope is completed.
 * A debugging breakpoint is reached.
 * A message is sent. The only exception to this is when a message is sent from an atomic transaction scope.
 * The orchestration starts another orchestration asynchronously, as it does with the Start Orchestration shape.
 * The orchestration instance is suspended.
 * When the orchestration engine is asked to shut down, the orchestration engine tries to save control information and the current state of all running orchestration instances. This behavior lets the orchestration engine resume running orchestration instances when the engine is started again. If the orchestration engine cannot save the current state, the orchestration engine resumes the orchestration instance from the last persistence point that occurred before the shutdown. This behavior applies to the system shutdown in a controlled condition and after an abnormal termination.
 * The engine determines that the instance should be dehydrated.
 * The orchestration instance is finished.

Serialization
All object instances to which an orchestration refers directly must be serializable for an orchestration state to be persisted. This requirement also applies to object instances that are referred to indirectly, or through other objects. There are two exceptions:
 * You can have a nonserializable object that is declared inside an atomic transaction. You can do this because atomic scopes do not contain persistence points.
 * System.Xml.XmlDocument is not a serializable class. This class is handled as a special case and can be used anywhere.

Caution For a .NET object to be persisted, it must be marked as serializable.

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

System shutdown
When the orchestration engine is asked to shut down, the orchestration engine tries to save control information and the current state of all running orchestration instances. Then, the orchestration engine can resume running them when it is starts again. If the orchestration engine cannot save the current state, the orchestration engine resumes the orchestration instance from the last persistence point that occurred before the shutdown. This behavior applies to the system shutdown in a controlled condition as well as to an abnormal termination.

Recovery
The engine regularly saves state information about an orchestration instance to persistent storage. The engine also saves the state if there is a system shutdown. When an orchestration instance fails abnormally for whatever reason, the instance can be recovered from the last persisted state and can continue to run as if there were no interruption. This is true even if the original server on which the instance ran goes out of service for some reason. The instance can resume running on a separate computer. Because of this multiserver recovery model, you no longer require clustering.

Keywords: kbtshoot kbinfo KB926627

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.