在拜读了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的问题也相应变得更加灵活,更能满足复杂业务逻辑的需要了。