WF from Getting started to proficient (sixth chapter): Loading and unloading instances

After completing this chapter, you will learn:

1. Understand why workflow instances are unloaded and reloaded and their timing

2. Understand why the workflow instance should be persisted and its timing

3. Build SQL Server 2005 to provide support for WF and workflow persistence

4. Use of SqlWorkflowPersistenceService services

5. Loading and unloading instances in your workflow code

6. Enable the persistence service to automatically load workflow instances and unload idle workflow instances

If you take the time to really think about how to use WF and workflow in your application, many of the solutions you might imagine include those that take a long time to run. After all, commercial software is essentially the simulation and execution of business processes, many of which involve people or vendors, ordering and shipping, scheduling, and so on. People do not automatically respond to processing in milliseconds, but they can do so on a loaded enterprise server. The server is a valuable, busy resource that requires a thread to rotate, and it is unacceptable for threads to wait a few minutes, hours, or days or weeks for many reasons.

So the WF designer must provide a mechanism for the idle workflow to be temporarily offline while waiting for some long-running tasks. WF decides to provide Microsoft SQL Server as an optional storage medium because the database is a good place to store (rather than lose) valuable data. WF also integrates another pluggable service, which we can easily incorporate into our workflows to support its persistence mechanism. How to do this, why and when to do it is a problem we will explore in this chapter.

Persisting Workflow Instances

Do you know that the modern Microsoft Windows operating system is essentially a very special batch software that is responsible for allocating processor time for each request thread? If a single thread monopolized the processor for an excessive period of time, other threads would "starve" and the system would deadlock. So this batch software, the Task Scheduler, moves the thread from the processor's execution stack and removes it so that all threads can get execution time.

In a sense, the workflow is similar. If you have a lot of long-running workflows that hang onto a particular computer to compete for processing time and resources, the system will eventually block the unhandled workflows. This has no scalability. In fact, WF is very efficient at maintaining its workflow queues, but you may agree that these must have a physical upper limit, and it is a good idea to remove idle, long-running workflows from the activation execution state.

Or what happened, the system was suddenly shut down? Workflows are handled entirely in memory unless we take steps to persist them. Therefore, unless we are prepared before an unexpected event, we will lose the workflow instance in execution. If those long-running workflows are managing key processes, are they lost and can we afford it? In most cases, we cannot afford to, at least we will not willingly allow these processes to vanish without precautions.

The good news is that WF not only gives you a way to unload a workflow instance and then reload it, it also supports a service: SqlWorkflowPersistenceService, which is used to serialize a workflow instance into a SQL Server database. If you have read the previous chapter, you may be familiar with, or even satisfied with, the idea of writing workflow instance information to the database.

So, at what time does the workflow instance unload, and if they are unloaded, how do we persist them? There are some very special points in the execution to unload the workflow instance. In most cases, this happens when we automatically consume resources and process time in memory unnecessarily for a long-running workflow that is not left (or unwilling to leave) for the--WF that I mentioned earlier. But we can also control it ourselves. This lists the uninstall points for the workflow instance, where they can be persisted.

1. After the ActivityExecutionContext completes and ends (unloads). We briefly talked about ActivityExecutionContext objects in the fourth chapter (Introduction to Activity types and workflow types).

2. When the activity enters an idle state.

3. Once a transactionscopeactivity is completed (unloaded). We will see this activity in chapter 15th (Workflows and transactions).

4. Once an activity with a Persistoncloseattribute attribute is completed.

5. When you explicitly call workflowinstance.unload or workflowinstance.tryunload.

You can control the time that a workflow instance is persisted by calling a specific method of the WorkflowInstance object or by using a delay activity to get your workflow into the idle state. In time of delay, you can control the automatic persistence behavior by passing a parameter to the constructor of the persistence service.

Note: Pausing the workflow instance and delaying the workflow instance is not the same. Using the delay activity will automatically write the workflow instance to the database (provided you are using SqlWorkflowPersistenceService and have configured it, as you will see in the last section of this chapter). Pausing simply causes the workflow to be withdrawn from the active processing state. However, you can also choose to manually write workflows to the database using unload or tryunload.

How does WF do this? This completes this task by using SqlWorkflowPersistenceService and creating a specific database (this is much like the Tracking database we created in the previous chapter). You can use related scripts to create a database schema (tables and views) and to perform the stored procedures required for persistence. Let's start by creating a database.