BizTalk 2009 Orchestration Dehydration and Persistence Points

Introduction
I am going to describe the Orchestration Dehydration and Persistence Points.this post for understanding why and how BizTalk use these.So let’s go quickly.

Dehydration
We know that BizTalk some times depending on other external application, so it is possible to ask BizTalk for waiting the other external application responses this my consume a lot of resources and memories, Instead of just waiting, the orchestration will dehydrate, and the state of the instance is taken out of memory and stored in SQL Server. BizTalk does this to free up valuable resources
for other processes and special subscription will be created for the dehydrated instance of the orchestration.This subscription will monitor the BizTalk message box for context properties
that match your unique correlation ID. When the subscription comes across that message, the
orchestration will “wake up,” and the state of the instance will be taken out of the database
and reconstituted in memory. The point at which the orchestration will, essentially, come alive
is known as a persistence point.
Persistence Points
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.
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.Debugging breakpoint is reached.
3. 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. 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.

I hope this help…………