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:
For the correct persistence and system shutdown information for
BizTalk 2004, see the "MoreInformation" section.
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.
