Click here to Skip to main content
Click here to Skip to main content

Persistence Point in BizTalk 2004

By , 18 Aug 2006
Rate this:
Please Sign up or sign in to vote.

Introduction

This article aims to give an overview of BizTalk 2006/2004 Persistence Point for developers.

Serialization

Serialization is the process of producing an object into a certain form of information bits. In general, serialization takes place in two scenarios:

  • Data Transfer: Serializing a class or structure to transfer over the network
  • Persistence: Serializing an object’s current state in a permanent storage media such as disk for later use

Modern programming languages like Java and C# provide a special library to serialize an object.

Persistence Point

What if your Internet browser closed unexpectedly when you were composing a big email?
Do you re-compose again? Let us say your email provider saves your composing mail as draft every 15 seconds automatically (e.g. Google mail), wouldn't you feel it’s a better option?
The process of saving your running orchestration state at a certain point is called persistence, in other words, storing the state into Biztalk database.

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

List of Persistence Points

Biztalk orchestration engine calls persistence operation on one of the below listed events that occurs:

  • End of a transactional scope (atomic or long running)
  • At debugging breakpoints
  • At the execution of other orchestrations through the Start Orchestration shape
  • At the Send shape (except in an atomic transaction)
  • When an Orchestration Instance is suspended
  • When the system shuts down in a controlled manner
  • When the engine determines it wants to dehydrate
  • When an orchestration instance is finished

Let us now identify persistence points in the orchestration shown below.

Diagram

Sample image

The above diagram depicts the places where persistence point occurs. I will explain to you again the reason for persistence in each step.

  1. No Persistence point, since the send shape is wrapped up in atomic scope
  2. Atomic scope end persistence
  3. Start orchestration persistence
  4. Break point persistence
  5. Send shape persistence; note the send shape out of atomic scope
  6. End of orchestration persistence

Any .NET object used in orchestration must be marked as [Serializable], unless the object is wrapped up in atomic scope or if the objects are stateless and called by static methods or objects created /derived from System.Xml.XmlDocument.

Performance and Persistence Point

The less Persistence points you have in your orchestration, the more efficient it works. In simple terms, each persistence point hits the database to store the current instance state.
We cannot avoid such a nice feature completely in our orchestration, but it can be reduced to more database round trips using atomic scope.

Any persistence point inside the atomic scope is serialized only at the end of scope.

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.

Minimize the Persistence Point

There is no such recommendation given by Product group. But splitting your orchestration with multiple atomic scopes will minimize the persistence point. There are certain cases you cannot use atomic scope, in that case you cannot avoid persistence points.

Test Persistence Point

In order to check the number of persistent points marked per orchestration, create a new host for test TestBox say “TestHost” and deploy your orchestration in that host. (Note: Only one interface should be deployed and tested at a time). Use perfmon tool, otherwise Trigger your orchestration and Use SQL Profiler to trace and count the number calls to the bts_InsertDynamicStateInfo_<TestHost> Stored procedure.

Conclusion

In order to avoid any persistence point issue in Test phase, the developer should take care while designing an orchestration. I hope this article would help you in understanding the Persistence point in turn avoiding unnecessary database round trips.

History

  • 18th August, 2006: Initial post

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Selvan
Software Developer (Senior)
United States United States
Tamilselvan Subramanian is a Lead consultant working on Microsoft Technologies for the past 6 years, Currently living in Newyork, US. Technical experience most specifically Biztalk 2004/2006, Webservices, C# and .NET framework,VB.NET, XML, XSLT, Flat file,Java.
 
He was awarded 'Community Star' by Microsoft for resolving .NET community people questions.
http://www.microsoft.com/india/communitystar/CurrentSelections.aspx
 
He blogs @ http://biztek.blogspot.com here.
You can reach him at tamilselvan +2 gmail.com.

Comments and Discussions

 
Generalnice article PinmemberUsman Shaheen29-Aug-06 0:34 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.140415.2 | Last Updated 18 Aug 2006
Article Copyright 2006 by Selvan
Everything else Copyright © CodeProject, 1999-2014
Terms of Use
Layout: fixed | fluid