避免 System.Transactions 中事务升级的策略
因此，根据我之前的问题的答案，如果在事务期间打开多个连接，即使所有连接都具有相同的连接字符串，事务确实会从 LTM 提升到 DTC。
所以，我的下一个问题是，可以采用什么策略来避免这一“功能”？ 在我看来，根据资源使用情况，我想确保尽可能多地使用 LTM。 我能想到的唯一方法是，在正确的面向对象的业务逻辑层中，在数据访问层创建一个请求级静态连接对象，并在调用之间共享该对象，直到请求完成（此处隐含的知识）一方面，业务对象实体是谨慎的，不知道调用它们的顺序，另一方面，人们不希望将连接对象冒泡到业务对象层，因为这将是数据存储实现细节渗入另一层）。
还有其他人有任何不完全破坏 n 层系统的层封装的想法吗？
So, based on the answer to my previous question, transactions do get elevated from the LTM to the DTC if multiple connections are opened during a transaction, even if the connections all have the same connection string.
So, my next question is, what strategies could one employ to avoid this "feature?" It seems to me that, based on resource usage, I want to make sure the LTM is used as much as possible. The only way I can think of doing that, in a properly object-oriented business logic layer, is to make a request-level static connection object at the data access layer and share that amongst calls until the request is complete (the implied knowledge here is that the business object entities are discreet and don't know what order they'd get called in, additionally is the fact that one would not want to bubble a connection object up to the business object layer as that would be data storage implementation details bleeding into another layer).
Does anyone else have any ideas that don't completely ruin the layer encapsulation of an n-tier system?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我使用的是 TransactionHelper 类，它更新 TableAdapter 中的所有命令，以将连接和事务替换为启动事务的 TableAdapter 中的命令。 您可以找到一些执行此操作的代码，您可以将其改编为需要，请参阅 Scott Lanford 的博客 CodeExperiment。 Ryan Whitaker 有一个类似的方法。
请注意，自从我改用 LINQToSQL 后，我就不再遇到这个问题了。 您可能需要考虑使用 LINQToSQL 或 nHibernate 作为替代解决方案。 两者都会对本地交易有良好的支持。
What I've used is a TransactionHelper class update all the commands in a TableAdapter to replace the connection and transaction with those from the TableAdapter that initiates the transaction. You can find some code that does this, which you can adapt as needed, on Scott Lanford's blog, CodeExperiment. Ryan Whitaker has a similar approach.
Note that since I've moved to using LINQToSQL I no longer have this problem. You may want to consider using LINQToSQL or nHibernate as a alternate solution. Either would have good support for local transactions.
我建议编写一个包装类来管理连接、事务、命令对象，这就是整个数据库的事情。 它是一种非常轻量级的 nHibernate。 该类将提供executeStatement(...)、executeQuery(...)、addParameter(...)、startTransaction(...) 等方法。
启动事务时，您可以提供一些（如果需要唯一的）标识符，您可以将有关同一事务的所有后续请求绑定到该标识符。 然后，该包装类将保存到哪个事务正在使用哪个连接运行的静态映射，并且将自动使用正确的映射或根据需要创建一个新映射。
您将从这种方法中获得一些额外的功能，因为您将集中所有持久性内容：
I'd recommend writing a wrapper class for managing connections, transactions, command objects, that's the whole DB things. It's kind of a very lightweight nHibernate. This class would provide methods for executeStatement(...), executeQuery(...), addParameter(...), startTransaction(...) and so on.
When starting a transaction, you could provide some (if needed unique) identifier to which you could tie all following requests regarding the same transaction. This wrapper class then would hold a static mapping to which transaction is running with which connection and would automatically use the right one or create a new one as needed.
You will get some extra features from this approach as you will have centralized all your persistence stuff:
我确实想问，如此努力避免DTC的原因是什么？ 在这个或之前的答案中没有提及原因，并且看起来好像您可能患有过早优化综合症。
I do have to ask, what is the reason for trying so hard to avoid the DTC? There is no mention in this or the previous answer as to why and it comes across as though you might be suffering from premature optimization syndrome.
正如 Casper 所说，尽管 DTC 很重要，但避免它可能还为时过早。 您可以使用静态工厂实现连接，以便简单地返回新对象，然后如果您确定有问题，您可以实现一种机制，可以将事务存储在 aa TLS（或 httpcontext，如果您使用的是 ASP）中。 并且不必更改任何代码。
这个问题实际上已经被提出并回答了，但当我找到它时我找不到它，我会更新这个。
As casper stated, avoiding the DTC might be premature although it is a significant weight. You could implement your connections using static factories so that simply return new objects, then if you determine you have a problem you could implement a mechanism that can store the transactions in a a TLS (or httpcontext if your in ASP). And not have to change any code.
This question has actually been asked and answered but I can't find it when I do I will update this.