Forum post about Persistence, IEventActivity, Transactions, and Correlation


http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=488698&SiteID=1&mode=1


There was a great set of questions that showed up on the forum the other day and I've finally gotten around to answering them all.  I was planning on posting the answers in this blog, but instead I'll just reference back to the forum post.


Summary:
* What is persisted with a workflow instance and what state am I in after a computer crash?
Queues, the internal list of scheduled items, and the binary serialization of the workflow tree are all persisted.  Reloading an instance after a workflow crashes gives you the exact state you had at the last persistence point.


* I want a single activity which delegates work out to the host and then waits for notification that the work is done.  Should I use the ExternalDataExchangeService or a custom IEventActivity? 
If it must be a single activity then I would recommend a custom IEventActivity to enable use of the solution in the StateMachine and in EventDrivens in general.  This is a prime scenario for ExternalDataExchangeService, but the requirement for a single activity to do the work makes that a less than viable solution.


* How do I get persistence of the workflow to take part in the same transaction as cleanup of a database caused by an inbound event? 
Batching is your friend ... see the post for details of batching.


* What are the implications of dropping correlation from the Correlated Service Sample? 
In short, if you drop correlation you will risk getting a runtime exception.  If two activities are waiting on the same event at the same time then we will throw an exception when the second activity tries to "handle" the already handled message.


Comments (4)

  1. hba says:

    Hello I’m new to windows workflow and workflow architecture in general.

    I’ve been going through the tutorials and have an architectural/design question about the correlated communication scenario.  

    Does it make sense to:

    a) Use  Multiple workflow instances or

    b) Use a single instance with a communication service that is enabled through correlations.

    For example, in an order processing scenario where they may be thousands of orders going through the system per hour; does it make sense to have thousands of workflow instances (a one to one relationship between orders and workflow instances) or only one workflow instance?

    Thanks in advance.

  2. ntalbert says:

    hba,

    The answer to your question actually depends on your scenario.  Just like object oriented programming, you should model your workflows in the way that is most confortable for you.  So, consider the following:

    Online Shopping Cart

    In this scenario there are thousands of completely independent orders going at any given time.  You should opt for a 1 to 1 correspondence in this case where a single workflow instance manages a single order.

    This is fine to do with respect to resources because workflow does not use resources in the same way as typical programs.  The normal workflow instance will be idle more than 95% of its lifetime … they are characterized by short bursts of work to figure out what to do next with large periods of waiting for more stimulus from the outside world.  Additionally, an idle workflow does not consume any threads and depending on your host an idel workflow might not even take up any space in memory.

    What this boils down to is that in most scenarios you don’t have to optimize for a minimal number of workflow instances which gives you the freedom to implement your solution in the way that makes the most sense.

    Business to Bussiness Supply

    You can imagine a company that might have a few large customers and each customer has several concurrent orders in place.  There are a few different ways to model this.  First, you might not care to include the overall customer management as part of your workflow solution and this could simply degenerate to the shopping cart scenario above – a bunch of unrelated orders.

    Another option, however, would be to model a relationship with a customer as a single workflow which also manages each of the orders the customer currently has in the works.  Still another option is to break this down further by having the customer management workflow spawn other workflows to take care of each order giving you a heirarchy of flow.

    Once again, the point is that you should use the solution that you are most comfortable with and that best captures the spirit of the process which you are trying to model.

Skip to main content