我发现这篇关于使用表适配器的事务的好文章。然而,这篇文章并没有解释为什么需要甚至是可取的事务!
为什么值得我尝试在我的 TableAdapter 旁边实现事务?
我发现这篇关于使用表适配器的事务的好文章。然而,这篇文章并没有解释为什么需要甚至是可取的事务!
为什么值得我尝试在我的 TableAdapter 旁边实现事务?
假设当您正在将需要多个查询的内容保存到数据库时发生了一些不好的事情。当您开始保存操作时,您希望对已保存的所有数据进行什么处理?大多数开发人员希望使之前保存的数据无效。好吧..这就是事务的用途:您将所有保存逻辑封装在事务中,这样如果/当中间发生不好的事情时,什么都不会被保存。
有关交易主题的更多信息:http ://en.wikipedia.org/wiki/Database_transaction
“为什么”是将这些数据库操作作为更广泛事务单元的一部分执行,以便您可以以原子(全有或全无)方式提交该操作和其他操作,或确保您的读取和写入发生在相同的事务(以避免幻像/不可重复读取)。其实我不是适配器模型的忠实粉丝,但是......
如何; TransactionScope
会更简单,因为 ADO.NET 连接应该自动登记:
using(var tran = new TransactionScope()) {
// do work A
// do work B
// do work C
tran.Complete();
}
任务完成...
如果您曾经拥有多个表,并且希望在原子调用中对其进行保证更新,那么事务使这成为可能。如果没有事务,您可能能够更新一个表,然后第二个表失败并且您留下有问题的数据。例如,您可能有这样的情况,您有一个屏幕,想要通过单击按钮添加一个父记录和一堆子记录。如果没有事务,父级成功保存,但其中一个子记录会爆炸。使用事务,您回滚整个事情并要求用户修复数据问题。
你们在这里发布的每个内容对我来说听起来都不错,但我们不应该忘记,针对解决方案总是有优势和劣势例如在应用程序端管理事务(不管如何)你将增加网络流量,因为 .net 必须将所有命令发送到 SQL Server:
使用(var tran = new TransactionScope()) {
// do work A
// do work B
// do work C
tran.Complete();
}
在这种情况下,它必须发送“开始交易”和“提交”。
最糟糕的想法是如果在“//do work b”之后连接断开会发生什么?这意味着 .Net 将无法发送“回滚”或“提交”,因此我们将在 SQL Server 端打开可能导致死锁的事务。
事务允许您维护数据库中的数据一致性。通常最好在所有数据库更新/插入中引入事务。如果指定的存储过程由于任何原因失败,您总是回滚。