避免System.Transactions中事务升级的策略

Question

因此，根据对我以前的问题的回答，如果在事务期间打开多个连接，即使连接都具有相同的连接字符串，事务也会从LTM提升到DTC。

那么，我的下一个问题是，人们可以采取什么策略来避免这种“特征”呢？在我看来，基于资源的使用，我希望尽可能多地使用LTM。在一个正确面向对象的业务逻辑层中，我能想到这样做的唯一方法是在数据访问层创建一个请求级别的静态连接对象，并在调用之间进行共享，直到请求完成(这里隐含的知识是，业务对象实体是离散的，不知道它们将被调用的顺序，另外一个事实是，人们不希望将连接对象泡到业务对象层，因为这将是数据存储实现细节流入另一层)。

有没有其他人有任何想法不会完全破坏n层系统的层封装？

Answer 1

我所使用的是一个TransactionHelper类，更新TableAdapter中的所有命令，以将连接和事务替换为启动事务的TableAdapter中的连接和事务。您可以在Scott的博客CodeExperiment上找到可以根据需要进行调整的CodeExperiment。瑞恩·惠特克( Ryan )有一个相似方法。

注意，自从我开始使用LINQToSQL之后，我就不再有这个问题了。您可能需要考虑使用LINQToSQL或nHibernate作为替代解决方案。这两种方法都会为本地交易提供良好的支持。

Answer 2

我建议编写一个包装类来管理连接、事务、命令对象，这就是DB的全部内容。这是一种非常轻量级的nHibernate。该类将为executeStatement(.)、executeQuery(.)、addParameter(.)、startTransaction(.)提供方法诸若此类。

在启动事务时，您可以提供一些(如果需要的话是唯一的)标识符，您可以将有关同一事务的所有以下请求绑定到该标识符。然后，这个包装类将保存一个静态映射，该事务与哪个连接一起运行，并将自动使用正确的连接，或者根据需要创建一个新的连接。

您将从这种方法中获得一些额外的特性，因为您将集中处理所有持久性内容：

• 轻松记录所有用于调试、性能测试的语句
• 锁定/网络问题的自动重试逻辑
• DB提供程序的简单切换
• 基本上，使用nHibernate这样的持久性框架可以得到一些东西，但是更轻巧，也不那么复杂。

Answer 3

我必须问，为何要如此努力地避免直接贸易委员会呢？在这个或先前的答案中没有提到为什么，看起来您可能患有早期优化综合症。