本文共 1687 字，大约阅读时间需要 5 分钟。

workflow instance在运行的时候有可能持续相当长的时间，如果让其常驻内存，将极大的影响性能，而且在某些特殊情况下，比如asp.net上， workflow instance运行在server端，如果workflow instance走到一半server突然当机，则该instance的所有状态将不存在。所以需要在适当时候保存workflow instance的状态，有可能的话在适当时机将其从内存中卸载，必要时再读入。

MS提供了一种保存机制利用SqlWorkflowPersistenceService类将instance的状态存储在数据库中，该类继承于WorkflowPersistenceService，我们可以自己写一个继承于该类的类提供保存机制，MS有示例，不多说。

 将该类用数据库连接字符串实例化后添加到workflowruntime中去。每当workflow instance的状态处于WorkflowIdled的时候，workflowruntime将调用该类将数据保存在数据库中，此时你可以选择将workflow instance从内存中卸载，当重新读取该workflow instance时需要提供该instance的Guid号，如果是web形式的workflow则需要保存该workflow instance的Guid到自己的数据库，不能仅依赖SqlWorkflowPersistenceService类的存储，因为，如果当机的话，尽管 workflow instance的状态已经保存，但是没有对应该workflow instance的Guid号，workflowRuntime无法将该instance重新读入内存。使用 workflowRuntime.GetWorkflow（Guid）方法读入。 在实际操作中SqlWorkflowPersistenceService类带有多个自己的存储过程，并且必须配合创建好的表才能正确执行。所有的表的创建已经存储过程的建立均由微软提供的 SqlPersistenceService_Schema.sql和SqlPersistenceService_Logic.sql文件产 生。没有运行这2个sql文件的数据库是无法保存workflow instance的。现实中，如果运行本地程序的电脑和sqlserver不是同一台机器将产生莫名奇妙的错误，现象是workflow线程挂起。经查阅 论坛发现是DTC连接的问题需要在workflowruntime里添加如下的service：workflowRuntime.AddService (new SharedConnectionWorkflowCommitWorkBatchService("Data Source=139.24.254.39;Initial Catalog=SqlPersistenceService;User ID=sa;Password=111;"));为何要添加此服务亦或者DTC在整个过程中起什么作用，还需要进一步的研究。 SqlWorkflowPersistenceService不提供lock机制。目前程序已经可以顺利运行了，在web上也已经初步实现，但是对SqlWorkflowPersistenceService类内部的机制，比如如何调用存储过程的，保存workflow instance的哪些数据等机制还很不了解，只有慢慢摸索了。 最后需要强调的是，所有的workflow instance均是运行于不同于启动workflowruntime的线程上的，主线程很多情况下需要等待workflow线程的运行。适时的调用 static AutoResetEvent waitHandle = new AutoResetEvent(false);中的 waitHandle.WaitOne();方法阻塞某些线程然后使用waitHandle.Set（）方法恢复是一个比较好的解决方法。 

本文来自CSDN博客，转载请标明出处：