BizTalk Orchestration – Understanding Persistence points

Posted: October 23, 2009 in BizTalk
Tags: , ,

What are Persistence Points?

Often ignored, but a really important, persistence points in Biztalk 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 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, but 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 persist 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 persistance 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 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 minimize persistence point

  • We cannot avoid such a nice feature completely in your orchestration, but can be reduced more database round trips using 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
    • 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 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 nonserializable 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.

Tags: BizTalk | Orchestration | Persistence

Comments
  1. […] For more information: BizTalk Orchestration – Understanding Persistence points […]

  2. […] Sandro perreira (a great biztalk MVP) wrote a great article about it : https://sandroaspbiztalkblog.wordpress.com/2009/10/23/biztalk-orchestration-%E2%80%93-understanding-p… […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s