windowsWorkflowPersistence--均衡负载下的持久化

这些天写了一些工作流持久化方面的东西。对微软这套通过服务挂接的方式对功能进行扩充的思想应用到服务提供者确实是很好的思路。开发者在不可能枚举所有实际的应用场景的前提下，这种方式给我一个很好的解决方案。呵呵撤远了，说到workflow的持久化，微软其实已经提供了一些基本的解决方案示例。大家可以看一下SqlPersistence的例子。详细的可以参照http://www.cnblogs.com/wzcheng的地址自己建一个库，看看SqlPersistence中的表结构和存储过程是怎么实现持久化和轮询的我就不乱说了:P 呵呵~那我到底要说什么呢。晕，忘记了等我想想。10分钟后....
均衡负载下的持久化服务，这才说到点子上。由于工作流的应用领域就目前来看主要是企业OA应用居多（其实我一直觉得工作流的应用领域可以很宽泛，大家不要被“工作流” 这几个名字所迷惑）。那么负载问题一定是不能不考虑的。微软提供的文件、SQL持久化都是基于一个host的有状态的持久化服务。在多个Host下怎么保证持久化数据的一致性，特别是延时唤醒后host的变更或是某个宿主的崩溃是我们不得不考虑的问题。其实在微软的例子里已经有了解决的答案，通过锁的机制和持有时间是可以缓解这个问题的，但其实那是给用户或业务系统使用的一种被动机制，我们并不能决定用户对一个流程的持有时间是多久。并且也不能保证用户访问的host是永远不变的。但这样一种暗示对于workflow的开发者来说已经足够了。通过增加宿主标示和唤醒时间让多个host在拿到Instance时保持状态，也就是说一个Instance一但被host持有那么她就不能被其他host持有。直到她被持有她的host释放。那么如何保证系统突然崩溃能宿主的host被释放呢。这里就需要对每个宿主的启动guid进行注册，每个host在启动的时候都会获得一个唯一的guid和这个guid的存活期。一旦超过这个存活期的注册信息都是无效的。当然在轮询的时候要不断的更新自己的注册时间，这样就可以长生不老啦:)当然如果宿主死亡，自然不会更新注册。那么使用这个已经死亡的宿主进行注册的Instace就会被释放，这样就可以被其他的host再次拥有。这里顺便说一下，我使用的是NOD作为数据访问组件，由于已经内置有乐观锁的机制，我就不多费心了。大家如果是直接进行数据库访问的要特别注意一下。防止可能造成的数据混乱。今天就记这么多了，不记时间长了自己都忘了呵呵。