Linq to Sql : 三种事务处理方式
-
隐式事务
当调用SubmitChanges 时,L2S会检查当前环境是否开启了事务(下面两节中创建的事务),如果没有开始事务,则 L2S启动本地事务(IDbTransaction),并使用此事务执行所生成的 SQL 命令。使用Reflector查看DataContext.SubmitChanges的源代码(见本文最后的附录),可以看到,如果开启了一个事务,并将其传给DataContext.Transaction,则在执行SubmitChanges时就不会再重新开启一个新的事务了。
OK,现在可以放心了,这里的确是先执行Insert,再执行Update;执行Update时出现了SqlException异常。这时查看测试表TLINQ中的数据,发现没有插入新的记录进去。也就是说,这里使用了事务,但是SQL Server Profile没有跟踪到。
至于为啥会这样,我暂时也没有搞清楚;还有就是下面一节中即使执行DbConnection.BeginTransaction(),也不会跟踪到begin tran和commit tran。不知道是不是SQL Server 2008里面升级了啥。哪位如果知道原因,麻烦告知我一声,谢谢。最后总结一下隐式事务的优缺点:
优点:使用简单,L2S都帮我们搞定了,我们不需要写任何代码。
缺点:只能处理单个DataContext中的单个SubmitChanges()函数的调用。如果需要将SubmitChanges()与其他自定义更新操作(譬如ExcuteCommand)共用一个Transaction、或者与其他DataContext共用一个DBTransation,就没辙了…
-
显式本地事务
SubmitChanges只能处理最基本的CUD(Create/Update/Delete)操作;而在日常的应用中,逻辑往往没有这么简单,或者考虑性能等因素,我们需要配合ADO.Net执行原生的TSQL;这时我们可能要让ADO.Net + Linq to SQL来进行配合处理。
优点:可以配合Ado.Net一起使用,或者跨DataContext使用,实现负责的业务逻辑。
缺点:处理步骤比较繁琐。L2S中的DataContext已经提供了ExcuteCommand方法来执行原生的TSQL,这里还这样使用Ado.net就太折腾自己了.......
- 显式可分发事务
使用TransactionScope来进行显示可分发事务控制。TransactionScope就像事务处理里面的一面魔镜,如果需要事务,就对着它喊:“主啊,请赐我事务!”,于是这个操作就有了事务功能。关于TransactionScope的详细介绍,可以参考MSDN:使用事务范围实现隐式事务,及SQL Server的联机丛书:CLR 集成和事务
灰常灰常地简洁,把要执行的操作封装在一个或多个Action中,然后传递给TransactioExtension.Excute即可。对于封装在TransactionScope里面执行的所有操作(譬如SubmitChanges,ExcuteCommand、ExecuteQuery),最终都会解析为对ADO.NET的调用;而ADO.Net会在调用 Connection.Open 方法时自动检查Transaction.Current,并在该事务中以透明方式登记连接(除非在连接字符串中将 Enlist 关键字设置为 false)。
SqlConnection 对象的 ConnectionString 属性支持 Enlist 关键字,该关键字指示 System.Data.SqlClient 是否检测事务上下文并在分布式事务中自动登记连接。如果此关键字设置为 True(默认设置),则会在打开的线程的当前事务上下文中自动登记连接。如果此关键字设置为 False,则 SqlClient 连接不会与分布式事务交互。如果未在连接字符串中指定 Enlist,并且如果在打开相应连接时检测到一个分布式事务,则会在此分布式事务中自动登记此连接。(FROM Sql Server 2008 联机丛书)