在拜读了idior兄的Transaction in ADO.net 2.0之后，偶也忍不住手痒，写下了关于J2EE Tranaction的几个基本概念一文。在阅读以及总结的过程中，我发现在Transaction的支持上，ADO.net仍需继续努力的哦。也许你会认为我瞎说，那么就来看一下两者Transaction Scope Option上的对比吧。
首先，Transaction Scope主要是解决在方法调用过程中Transaction嵌套的问题。ADO.net 2.0在Transaction Scope上提供的Option有三个：Require，Requires New和Suppress。在idior兄的Post里面，还有一张表和一个示意图，你是否都看懂了呢？表中列出的六种情况，你又是否了然于胸了呢？以下图表引用于idior兄的Post：
1. 表中的第一行对应着图中Code block with no ambient Transaction对Scope1的调用。对照表中的第三列：New Transaction。我们可以得出，当一个与Transaction无关的MethodA调用了Transaction Scope为Required的MethodB，Transaction Manager将会为MethodB创建一个新的Transaction，这个新的Transaction就对应着图中Transaction A。
2. 表中的第二行在图中没有画出来，可类比第五行。
3. 表中的第三行在图中没有画出来，可类比第六行。
4. 表中的第四行在图中对应着Scope1对Scope2的调用。对照表中的第三列：Ambient Transaction。 我们可以得出， 当一个与Transaction有关的MethodA调用了Transaction Scope为Required的MethodB， Transaction Manager并不会创建新的Transaction，而是让MethodB与MethodA所在的Tranaction关联起来。
5. 表中的第五行在图中对应着Scope1对Scope3的调用。对照表中的第三列：New Transaction。我们可以得出，当一个与Transaction有关的MethodA调用了Transaction Scope为Requires New的MethodB， Transaction Manager会为MethodB创建一个新的Transaction，这个新的Transaction就对应着图中的TransactionB了。
6. 表中的第六行在图中对应着Scope1对Scope4的调用。对照表中的第三列：No Transaction。我们可以得出，当一个与Transaction有关的MethodA调用了Transaction Scope为Suppress的MethodB， Transaction Manager既不会为MethodB创建新的Transaction，也不会将MethodB与MethodA所在的Transaction关联起来。
总之，Required会视调用者的情况决定是否创建新的Transaction，而另外两个Option则不管调用者的情况如何，都会有一致的结果。打个比方吧，Required意味着精打细算，原来存在Transaction就拿来用，没有才会创建一个新的；Requires New就意味着要求纯粹了，不管你原来有没有Transaction，到了偶的地盘都得有Transaction；Suppress就是不理不睬了，管你原来有没有Transaction，反正俺这里不要。
说完了ADO.net的情况，就让我们来看看J2EE下面的Transaction Scope Option吧。在J2EE的文档中，会有一个特别的名词Transaction Attribute与ADO.net的Transaction Scope Option想对应。 Transaction Attribute有六个可选值：Required，Requires New，Mandatory，Not Supported，Supports和Never。为了不再重复上面繁琐的陈述，还是用下面的图表来说明这几种Attribute的含义吧：
Figure1. Invoker with no client transaction
Figure2. Invoker with client transaction
从以上的图表，你可以发现两者的Required和Requires New是对应的，而Not Supported则对应于ADO.net中的Suppress。而Mandatory，Supports和Never则是J2EE下特有的。正是因为增加了这三个Attributes，所覆盖的可能性范围就增大了许多，处理Transaction Scope的问题也相应变得更加灵活，更能满足复杂业务逻辑的需要了。