SqlTransaction 中的 SqlDataAdapter.Fill() - 这是一个不好的做法吗？

Question

由于我有一个带有DataSet QueryDB(string spName, DBInputParams inputParams) 方法的“DB util”类，我将其用于对数据库的所有调用，因此我想重用此方法以支持事务调用。

所以，最后我将在 SqlTransaction 中有一个 SqlDataAdapter.Fill。这会是一个坏习惯吗？因为我很少在事务中看到 DataAdapter.Fill 的用法，更常见的是 ExecuteReader()。有什么问题吗？

Edit1：问题是我的事务中经常需要检索一些数据（例如自动 ID）...这就是为什么我想将它作为 DataSet 获取。

Edit2: 奇怪的是，当我在来自 2 个不同进程的 for 循环 (10000) 中使用这种方法时，我得到“事务（进程 ID 55）与另一个进程在锁定资源上死锁并且有被选为死锁受害者。重新运行事务。” .这是正确的行为吗？

Edit3：（Edit2 的答案）我使用的是IDENT_CURRENT('XTable')，这是错误的来源。回SCOPE_IDENTITY()后，一切都解决了。

Answer 1

这不是不好的做法。要记住的一件事是，所有语句都将使用隐式事务，它们将在语句结束时自动提交。那是一个 SELECT（如 Fill 使用的 SELECT）将始终使用事务，问题是它是否必须自己启动它还是将使用现有的。

SELECT 在隐式事务和显式事务中获取的锁的数量、类型和持续时间之间有什么区别吗？在默认事务模型（READ COMMITTED 隔离）NO下，没有。行为相同且无法区分。在其他隔离级别（可重复读取、可序列化）下存在差异，但这是发生所需更高隔离级别的必要差异，并且使用显式事务是实现所需隔离的唯一方法水平，必要时。

此外，如果 SELECT 必须读取待处理（尚未提交）事务的影响，如您的示例（读回生成的 ID），那么 没有其他方法。 SELECT 必须是生成 ID 的事务的一部分，否则它将无法看到那些未提交的 ID！

但请注意。我相信您有一个很棒的工具可以让您更轻松地处理所有这些事务：System.Transactions。所有 ADO.Net 代码都是系统事务感知的，如果您简单地声明 TransactionScope，它将自动将任何连接和命令注册到挂起的事务中。也就是说如果函数Foo声明了一个TransactionScope然后调用函数Bar，如果Bar做了any ADO.Net操作，它会自动成为Foo中声明的事务的一部分，即使Bar做了没有明确。 TransactionScope 与线程上下文挂钩，所有由 Bar 调用的 ADO.Net 调用将自动检查此上下文并使用它。请注意，我的真正意思是任何 ADO.Net 调用，包括Oracle 提供者的调用。唉，虽然有一个警告：using new TransactionScope() Considered Harmful：TransactionScope 的默认构造函数将创建一个可序列化的事务，这是矫枉过正的。您必须使用接受TransactionOptions 对象的构造函数并将行为更改为ReadCommitted。 TransactionScope 的第二个问题是您必须非常小心如何管理连接：如果您在一个范围内打开多个连接，那么它们将被注册到分布式事务中，这很慢并且需要配置 MSDTC，并导致各种难以调试的错误。但总的来说，我认为使用TransactionScope 的好处超过了问题，并且生成的代码总是比明确传递IDbTransaction 更优雅。

Answer 2

这是一种不好的做法，因为当事务处于打开状态时，您对其进行更改的记录/页面/表在事务期间被锁定。填充只会使整个过程使这些资源锁定更长的时间。根据您的 sql 设置，这可能会阻止对这些资源的其他访问。

也就是说，如果有必要，有必要，只要意识到这样做的惩罚。