microsoft press windows workflow foundation step by step phần 4 ppt

Chapter 6 Loading and Unloading Instances 105

6. If you expand the Databases node in Object Explorer, you should find the new

WorkflowStore database has been added.

7. Next we’ll need to execute the scripts I mentioned that .NET 3.0 provides for

persistence, starting with the schema script. As before, the scripts are located in

<%WINDIR%>\Microsoft.NET\Framework\v3.0\Windows Workflow Founda￾tion\SQL\EN, where <%WINDIR%> is your Windows directory (typically, C:\Win￾dows). From SQL Server Management Studio’s File menu, select Open and then File,

which brings up the common Open File dialog box. Using the controls in the Open File

dialog box, locate the schema script, SqlPersistenceService_Schema.sql. Select that from

the available scripts, and click the Open button. Note that you’ll need to connect to your

database server once again.

106 Part I Introducing Windows Workflow Foundation (WF)

8. SQL Server Management Studio will load the script into a new window, but before we

actually run the script, remember we’ll need to specify which database we want the

script to run against. Of course, we want to use the WorkflowStore database we just

created. Therefore, locate the WorkflowStore database in the drop-down list of databases

and select it as the target.

9. With the WorkflowStore database designated as the target of the script, execute the

script by clicking the Execute button on the toolbar.

10. Repeat steps 7 through 9 to execute the SqlPersistenceService_Logic.sql script. This loads

the necessary stored procedures into the database.

If everything worked as it should, we now have a database ready for workflow instance

storage. It’s time to plug SqlWorkflowPersistenceService into our workflow processing so that we

can use the database we just created.

Introducing the SqlWorkflowPersistenceService Service

If it becomes necessary to persist an executing workflow, something must actually perform

the persistence action. However, saving and restoring workflow instances is optional—you

don’t have to shuffle workflow instances off to a durable storage medium (such as a database)

if you don’t want to. So it probably makes sense that persistence is implemented by a

pluggable service, SqlWorkflowPersistenceService. WorkflowInstance works in concert with

Chapter 6 Loading and Unloading Instances 107

SqlWorkflowPersistenceService if the service is present when the workflow instance is running

to perform the save and restore tasks.

On the surface, this all sounds relatively simple. If we need to swap a workflow instance out to

the database, we just tell the persistence service to save it for us. But what happens if we’re

using a single database to persist workflows running in different processes? How do workflow

instances actually stop and restart in the middle of their execution?

It’s not uncommon for there to be a single database used for storing workflow instances. But

each instance might have been executing on different machines and possibly within different

processes on any given machine. If a workflow instance is saved and later restored, we must

have a way to also restore the system state that was in effect at the time the workflow instance

was executing. For example, SqlWorkflowPersistenceService stores whether or not the instance

was blocked (waiting for something), its execution status (executing, idle, and so on), and var￾ious and sundry informational items such as serialized instance data and the owner identifier.

All this information is necessary to rehydrate the instance at a later time.

We can control this persistence via the WorkflowInstance object through three methods,

shown in Table 6-1.

As Table 6-1 indicates, we have two methods available for unloading and persisting a work￾flow instance. Which method you use depends on what you intend for your code to do.

Unload waits for the workflow instance to become ready to be persisted. If this takes a long

time, the thread executing the Unload operation also waits a long time. However, TryUnload

will return immediately when asked to unload an executing workflow instance. But there is no

guarantee the workflow instance actually unloaded and persisted to the database. To check

for that, you should examine the return value from TryUnload. If the value is true, the work￾flow instance did unload and persist itself. If the value is false, the workflow instance didn’t

unload and persist. The advantage of TryUnload is that your thread isn’t sitting there waiting.

The disadvantage, or course, is that you might have to repeatedly use TryUnload to force out

the executing workflow instance.

Table 6-1 WorkflowInstance Methods, Revisited

Method Purpose

Load Loads a previously unloaded (persisted) workflow instance.

TryUnload Tries to unload (persist) the workflow instance from memory.

Unlike calling Unload, calling TryUnload will not block (hold up

execution) if the workflow instance cannot be immediately

unloaded.

Unload Unloads (persists) the workflow instance from memory. Note that

this method blocks the currently executing thread that made this

unload request until the workflow instance can actually unload.

This can be a lengthy operation, depending on the individual

workflow task.