WCF从理论到实践(12):事务-技术开发NET技术-Ubuntu系统_Ubuntu服务器

系列文章导航：

本文目的

通过阅读本文,您能了解以下知识

1) 如何在WCF中实现事务?

2) 谈谈事务隔离方式的相关知识

3) 事务的实现会给我们编程带来什么样的阻力?

4) 一笔带过,WCF是如何实现分布式事务的?

5) 代码不骗人,用一个银行存取款的范例来演练WCF事务

本文适合的读者

本文适合WCF初学者，学习本文之前，您最好阅读一下WCF从理论到实践系列文章的前几篇

如何在WCF中实现事务?

事务原本是一件难于实现的事情，可WCF总是能化腐朽为神奇，它能够通过简单的声明式编程方式，便可以实现分布式的事务，下面就来看下实现此目标的功臣：

1) TransactionFlowAttribute：操作契约(OperationContractAttribute)的一个属性，它能够指示所属操作(Operation)的事务选项(TransactionFlowOption)。

2) TransactionFlowOption：它是TransactionFlowAttribute构造函数中的参数，是一个枚举(enum),包括三个枚举项NotAllowed：不允许事务，是缺省值；Allowed：允许事务，意味着事务可有可无；Mandatory：强制事务，表示事务是必须的。

3) TransactionAutoCompleteOnSessionClose：它是操作行为(OperationBehaviorAttribute)的一个属性，用于标注事务完成之后,服务端实例是否自动释放，这个属性和服务对象实例模式紧密相关，使用的时候，应该着重小心，下面也会有说明。

4) TransactionIsolationLevel：也是操作行为(OperationBehaviorAttribute)的一个属性，用于指示事务隔离方式(isolation level).包括5中选项：Any，ReadUncommitted，ReadCommitted，RepeatableRead，Serializable，事务的隔离方式相关知识比较复杂，留作文章的第二点中将具体阐述

5) TransactionTimeout：也是操作行为(OperationBehaviorAttribute)的一个属性，用于指示事务的超时时间，默认为TimeSpan.Zero,表示不会受超时时间的限制..:: OperationBehaviorAttribute：也是操作行为(OperationBehaviorAttribute)的一个属性，用于指示分布式事务选项，如果设置为true，那么必须在事务范围(Transaction Scorp)内。

通过上面几个属性的使用，我们便能够轻松的在WCF中实现事务以及分布式事务。具体实现方式可以参考代码范例

谈谈事务隔离方式的相关知识

单纯的事务存在着下面三个问题

1) 脏读：简单的说就是事务一在某一时刻更改了数据，恰恰这个更改的数据被事务二读取，而事务一却最终失败，导致数据回滚，那事务二就是一个受骗者

2) 非可重复性读取：同一数据每次读取的结果都不一样就是非可重复读取。比如事务一要读取的数据务二改变，这就是非可重复性读取

3) 幻读：很简单，比如事务一在查询数据中，事务二却插入了一个符合查询条件的数据，这样就造成新插入数据的幻读。

三种问题的解释可能比较难于理解，其实简单的说，脏读是读了别人正在更改的数据，而可重复读取是更改了别人正在读的数据，而幻读呢则是读了别人还未来得及插入，更改或者删除的数据，我想这样理解就简单多了。

针对上面不同的问题，可以设置事务的不同隔离方式来防止问题的发生，事务的隔离方式又包括

1) Any: 组件的隔离级别是从调用组件的隔离级别获得的。如果组件是根组件，则隔离级别用于 Serializable 中。

2) ReadUncommitted：读取未提交数据，该方式在读取数据时保持共享锁定以避免读取已修改的数据，但在事务结束前可以更改这些数据，这导致非可重复读取或幻读。

3) ReadCommitted：读取提交数据, 发出共享锁定并允许非独占方式的锁定。该方式与读取未提交数据相相似，这种方式看似和读取未提交数据相似，但有一个区别，事务的只读锁在移到下一行的时候，会解锁，而写入锁却只有在事务完成或者被中止后才解锁，事务要等待所有写入锁解锁。

4) RepeatableRead：可重复性读取，与读取提交数据相似，在查询中使用的所有数据上放置锁，以防止其他用户更新这些数据。防止非可重复读取，但幻读行仍有可能发生。该方式是只读锁也要等到事务结束或者中止才解除

5) Serializable：在完成事务前防止更新或插入。

从上面的描述看，几种隔离方式比较难于区分，但它们能解决事务面临的不同问题，也许记住这些更方便的了解隔离方式

隔离级别	ReadUncommitted	ReadCommitted	RepeatableRead	Serializable
脏读	Yes	No	No	No
非可重复性读取	Yes	Yes	No	No
幻读	Yes	Yes	Yes	No

从上表可以看出隔离方式除了Any之外，一级比一级严厉。Any是一脉相承的，如果它没有可继承的，它将是最严厉的Serializable

事务的实现会给我们编程带来什么样的阻力?

1) 指定了TransactionFlow(TransactionFlowOption.Mandatory)，而Binding却没有设置TransactionFlow为true 此时会出现类似"Bank"协定上至少有一个操作配置为将 TransactionFlowAttribute 属性设置为"强制"，但是通道的绑定"WSDualHttpBinding"未使用 TransactionFlowBindingElement 进行配置。没有 TransactionFlowBindingElement，无法使用设置为"强制"的 TransactionFlowAttribute 属性。这样的错误提示。

2) 设置了[OperationBehavior(TransactionScopeRequired=true)]的操作，却没有在TransactionScorp中执行，会发生类似"服务操作需要事务成为流"的异常，截图如下：

3) 也许上面两个问题都是不是问题的问题，那这一点的确是需要我们研发人员注意的，否则我们会吃亏不少。这点涉及到事务和服务实例模式的联系，我们通过学习WCF从理论到实践:实例模式和对象生命周期 我们都学习到了实例在PerSession或者Single模式下不会每次都创建和消亡，这的确是一个不争的真理，可在这里却受到了挑战，不信你可以编写一个程序，即使用你最放心的Single模式，那时不是就是说服务实例是一次创建，终身受用呢？下面就看看我第一次编写范例程序后得到的运行结果，我如下定义Bank

可在调用的时候，我却发现了一个很奇怪的问题，按照理论来说，Bank服务实例应该只创建一次，可运行的截图却是如下：

这个结果是不是令大家大失所望呢？这是因为实现了事务的得服务还要受到TransactionAutoCompleteOnSessionClose的限制，该属性默认情况是true，它指示WCF在事务操作完成之后强制销毁服务实例，相当于调用服务的Dispose()方法进行释放，尽管是PerSession或者Single都难逃它的法网。如果想维持实例模式，可以将其设置为false,更改后运行效果便可如期望一致效果图不再给出。

4) 本文更多的实现了分布式任务，分布式任务要使用TransactionScrop这个类，有关它的一些注意事项可以参考我以前的这篇文章：两种实现事务方法的比较

一笔带过,WCF是如何实现分布式事务的?

WCF实现事务的依据是基于WS-AtomicTransaction标准，比较底层的东西，应该属于XXX内幕系列，本文不作详细阐述，如有兴趣，可以查看园子中Kevin Li 兄弟的几篇文章，我列在下面，希望Kevin Li不要见怪

1) 基于WS-AtomicTransaction标准的WCF远程分布式事务（一）

2) 基于WS-AtomicTransaction标准的WCF远程分布式事务（二）

3) 基于WS-AtomicTransaction标准的WCF远程分布式事务（补充）

代码不骗人,用一个银行存取款的范例来演练WCF事务

制作了一个小范例，用于演示事务的实现，示例的情形如下

存在两个服务：1）IATMServer:它是模拟银行的ATM机器的服务 2）IBank，它模拟银行的账户服务。建立一个客户端用于模拟ATM机，我们的操作步骤如下：

1) 插卡

2) 存款

3) 取款

4) 拔卡

操作比较简单，不做赘述，需要注意的是当取款的时候，如果取款金额大于余额的时候，系统会抱错，而账户余额不会更改。运行效果图