BizTalk Orchestration – Understanding Persistence points

What are Persistence Points?

Often ignored, but really important, persistence points in BizTalk Server are the key issue in dealing with Orchestration Performance. The SQL Server does bulk of the job at the backend to keep the BizTalk server running. BizTalk Server has this inherent behavior of saving the orchestration state to the SQL Server so as to quickly and easily recover from any failures. Persistence points are those points in the orchestration that save the orchestration state to the database.

Persistence Points induces latency in Biztalk Orchestrations, though you cannot avoid them, understanding them would help in using them efficiently

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.

List of persistence point

Orchestration engine persists your running instance based on how you designed your orchestration. There are few events or stages, which triggers the persistence operation called persistence points:

• Persistence at the BizTalk Engine level
  • When an Orchestration Instance is suspended
  • When the system shutdowns in a controlled manner
    • 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.
  • When the engine determines it wants to dehydrate
  • When an orchestration instance is finished
• Persistence in Orchestration level
  • The end of a transactional scope is reached (atomic or long-running)
    • 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 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.
  • At the execution of other orchestrations through the Start Orchestration shape
    • The orchestration starts another orchestration asynchronously. Note: Call orchestration shapes do not cause persistence points
  • At the Send shape
    • The only exception to this is when a message is sent from within an atomic transaction scope.
  • At debugging breakpoints

Performance and persistence point

In simple terms, the less Persistence point you have in your orchestration the more efficient it works. Each persistence point hits the database to store the current instance state.

The state includes

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

Tips to Increase performance by minimizing persistence point

• We cannot avoid such a nice feature completely in your orchestration but can be reduced more database round trips using an atomic scope.
  • Any persistence point inside the atomic scope is serialized only at end of scope.
  • Splitting your orchestration with multiple atomic scopes will minimize the persistence point
  • The performance of orchestration is really degraded, while you send more than 500 messages to the external system using send shape loop without an atomic scope.
  • Do remember the atomic scope is also serialized at the end.

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:

• You can have a non-serializable object 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; 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.