【正文】
设计支持事务的WCF服务
本章前面小节的内容为你展示了在WCF服务中如何实现事务，但是在设计支持事务的WCF服务时，仍然有许多问题值得你关注。事务、会话和服务实例模式
如果你在WCF服务中在一个或多个操作上设置OperationBehavior特性类的TransactionAutoComplete属性值为false，那么你必须设置服务实例模式为PerSession。这是因为WCF运行时需要在两次调用操作之间维护事务的状态。如果在每个操作上设置TransactionAutoComplete属性值均为true，WCF运行时则不必维护事务的状态，因为它在每个操作结束时完成当前的事务，此时你可以使用PerCall或者Single服务实例模式。当你使用PerSession服务实例模式时，ServiceBehavior特性类为WCF提供两个额外的属性：
- ReleaseServiceInstanceOnTransactionComplete，如果该属性设置为true，那么在每个事务结束时，WCF运行时将自动地结束会话并回收服务实例。如果客户端程序再调用另外一个操作，它必须创建并连接至一个新的服务实例。设置该属性为false将允许一个会话处理多个事务。该属性的默认值为true。
- TransactionAUtoCompleteOnSessionClose，如果该属性设置为true，当客户端程序关闭会话时，WCF运行时将自动完成当前的事务。该属性的默认值为false，当客户端关闭会话时，事务将被抛弃，事务所做的工作将被还原。
听起来，这似乎是一个缺点，但是实际上这非常有用。如果事务跨越多个会话存在，那么将不能保证一个事务曾经终止过，而且一个事务锁定的资源可能还保留了不确定的锁（其他事务可能也锁定了该资源）。
事务和消息传送
事务性操作把关于事务状态的信息回传至客户端程序。到目前为止所有定义的消息都遵循请求/响应模型；客户端程序发送请求，然后等待服务的响应。在第十二章"实现单向操作和异步操作"中你可以定义单向操作，这种类型的操作不需向客户端程序回传响应。请注意，单向操作不支持事务。事务和多线程
在第七章中你已看到，如果设置ConCurrencyMode属性为Multiple，那么WCF服务可以实现对操作的多个并发调用。当你使用该模式时应当注意下面几点：- 为服务中每个操作添加OperationBehavior特性，而且该特性类的TransactionAutoComplete属性必须设置为true。事务不能跨越多个操作。
- 为服务合约添加ServiceBehavior特性，而且该特性类的ReleaseServiceInstanceOnTransactionComplete属性必须设置为false。在客户端关闭连接时必须显示地释放服务实例。
- 为服务合约添加ServiceBehavior特性，而且该特性类的TransactionAutoCompleteOnSessionClose属性必须设置为true。当会话结束时所有线程上的事务必须终止。
在工作流服务中实现事务
WF在工具栏的消息模传送区域中提供TransactedReceiveScope活动，用以在工作流服务中实现事务性操作。该活动对外公开两个属性- Request，该属性必须是一个Receive活动，该活动定义了服务接受的消息，其标志操作的开始
- Body，该属性包含一个活动，该活动定义了操作的逻辑。一般地，你通过顺序活动处理客户端请求的数据以实现该活动。该活动还包含了一个SendReply活动用以回传响应消息至客户端
与非工作流WCF服务的定义方式和控制方式想对比，工作流服务中的事务性活动有根本性不同：
- 不能显示地指定工作流运行时如何完成事务（对于非工作流服务，没有TransactionAutoComplete特性的概念）。在工作流服务中，TransactedReceiveScope活动确定了操作的结果；如果Body属性中的Sequence活动定义的TransactedReceiveScope结束，并且没有发生任何异常，那么操作被认为成功的完成，并且当事务完成时进入提交过程。如果在Body属性中抛出了一个异常，事务将被抛弃。
- 在SendReply活动中事务性工作不会结束。在Body属性中定义的Sequence活动可以在发送响应结束后，包含其他的逻辑。这些逻辑中包含的工作也包括在同一个事务的范围内。只有当Sequence活动结束才能被事务性工作识别。请注意，这意味着工作流服务可能发送一个响应至客户端，然后执行其他一些可能失败的过程，然后再抛弃事务。但是在这种情况下，客户端程序可能并为立即获知事务失败，因此使用该特性时需加倍小心。
- 使用TransactedReceiveScope活动实现一个操作暗指TransactionFlowOption.Allowed。你不能指定一个操作必须在一个现存事务中执行（TransactionFlowOption.Mandatory）；如果一个客户端程序没有使用事务调用操作，工作流运行时将自动创建一个事务。此外，该事务的默认隔离级别为Serializeable，尽管这将被客户端程序创建的事务范围中隔离级别覆盖。
该工作流创建了一个TransactionScope活动，而该活动又包含一个顺序活动，然后在顺序活动中两次调用ChangeStockLevel操作。这两个操作都包含在同一个事务中。你可以在组件服务控制台中查看事务统计以确认这点。为了进行额外的检查，ChangeStockLevel自定义的活动将在控制台输出事务的详细信息。从下图中我们可以看到，两次调用ChangeStockLevel操作的事务ID相同。
长时间运行的事务
事务会锁定资源。为了减少对其他用户的影响，以及提高服务的高可用性和并发数量；应当设计运行时间尽可能短的事务，应在避免在事务执行过程中等待用户输入。尽管在本章中使用购物车服务演示了事务，但是其实现并不是最佳的实践（因为实际的情况与本章中的练习有较大的差别）；如果用户使用之前章节创建的GUI客户端访问ShoppingCartService服务，那么事务可能持续相当长的时间（你不能控制用户何时调用Checkout操作），在这期间资源一直被锁定。另外一个常见的场景就是B2B方案。企业间的事务持续很长一段时间（可能好几天），这是能经常见到的。如此长时间运行的事务你需要使用可替换的方案。常见的方案是：一个服务执行更新，然后立即释放相应的资源。这有效地将每一个更改做为一个单独事务。服务应当维持一个更改的列表。在后续的时间点，如果服务需要回滚这些操作，可以访问该列表，然后执行反向操作。该复原操作有时被称之为"补偿性事务"。WF提供的CompensableActivity活动就是为了实现该目的。
CompensableActivity活动提供一个Body属性，在该属性中你可以为长时间运行的任务定义工作流，比如等待客户端的输入，或者等待来自其他服务的消息。如果错误发生，你可以在CancellationHandler属性中定义补偿逻辑以复原Body属性中工作流所做的更改。如果Body属性中的工作流已经完成，你仍然可以在CancellationHandler属性中定义适当的逻辑复原更改。仅仅只有当CompensableActivity活动执行的工作被确认，那么所有的更改才当视为永久性更改。为了确认CompensableActivity活动执行的工作，你需要使用Confirm活动。
创建补偿性事务将会带来许多潜在问题。比如，如果其他用户在补偿性事务执行的期间内，已经对同一个数据做了进一步改变，它可能不可以恢复一个操作。此外，其他用户可以看到补偿性事务已经更改的数据，因次如果你复原这些操作，那么其他用户的事务可能产生某些不一致。
更多详细的信息，超出本书的讨论范畴，如果你有兴趣，请查阅MSDN http://msdn.microsoft.com/en-us/library/dd489432.aspx
【总结】
在本章，你已经看到如何在WCF客户端程序和服务中定义和控制事务。一个程序可以创建一个现存的事务列表，或者通过适当的参数实例化TransactionScope对象以创建一个新的事务。事务可以从客户端，通过网络，流向客户端。你可以通过ServiceBehavior特性类和OperationBehavior特性类在服务合约和服务的操作上指定事务的需求。在WCF服务的操作上通过执行OperationContext.Current.SetTransactionComplete方法以表明事务可以被提交。应用程序可以通过调用TransactionScope对象的Complete方法完成事务。
你了解到如何配置WCF服务和客户端程序，以在其收发的SOAP消息中包含关于事务的信息。你还了解到事务如何影响WCF服务的设计
最后，你还看到如何在工作流服务中使用TransactedReceiveScope活动实现事务。TransactedReceiveScope活动用以实现运行时间较短的事务。如果服务需要支持长时间运行的操作，那么应该使用定义了补偿逻辑的CompensableActivity活动，以避免长时间锁定资源。
最新评论