交易经理
如果我使用 .Net System.Transactions.TransactionScope 类来处理 Oracle 数据库中多个表的事务，将使用 LTM[轻量级事务管理器] 或 MSDTC[微软分布式事务协调器] 中的哪一个？
幕后是否有任何规则或策略来决定使用哪一种以及何时使用？ 请指教。 另外，想知道何时使用两阶段提交？是否仅在跨多个数据库的分布式事务时使用？
谢谢。
If I use .Net System.Transactions.TransactionScope class for a transaction across multiple tables in Oracle database, which one will be used LTM[Lightweight transaction manager] or MSDTC[Microsoft distributed transaction coordinator]?
Is there any rule or strategy beind the scenes for deciding which one to use and when?
Please advise.
Also, wanted to know when is 2-phase commit used?Is it used only incase of distributed transactions across multiple databases?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
基本的经验法则是，事务处理资源（例如数据库、队列、消息传递引擎、文件系统等）将选择其所知的最便宜且最轻的事务协调器（TC）。
MSDTC（或第 3 方替代方案）通常仅在事务跨越多个物理盒（这需要分布式 TC - DTC）或跨越多个资源（其中一个资源仅理解 MSDTC）时才会被调用。
对于完全在特定服务器应用程序内进行的交易，他们很可能会使用自己的内部 TC 或使用其运行平台上可用的最便宜的 TC。
Vista/Server2008 引入了内核事务监视器 (KTM)，它提供了非常快速的内置 TC。如果可用，System.Transactions 将使用 KTM，但如果不可用（例如，在 XP/Server2003 上运行时），将调用 MSDTC。
例如，KTM 允许更新驻留在同一个物理设备上的数据库、一些 (NTFS) 文件和 MSMQ 队列，而无需（成本更高）分布式事务。
遗憾的是，某些较旧的软件无法识别 KTM，并且在参与超出其本地范围的事务时可能会调用 MSDTC。
The basic rule of thumb is that a transacted resource (e.g. DB, queue, messaging engine, file-system, etc) will select the cheapest and lightest Transaction Coordinator (TC) that its aware of.
MSDTC (or a 3rd party alternative) is only generally invoked when transactions span multiple physical boxes (this requiring a Distributed TC - DTC) or if they span multiple resources, one of whom only understands MSDTC.
For transactions entirely within a particular server app, chances are that they'll use their own internal TC or use the cheapest TC available on the platform they're running on.
Vista/Server2008 introduced the Kernel Transaction Monitor (KTM) which provides a very fast on-box TC. System.Transactions will use KTM if available but if not (e.g. when running on XP/Server2003), will invoke MSDTC.
KTM allows one to, for example, update a DB, some (NTFS) files and an MSMQ queue that all reside on the same physical box without requiring a (more costly) distributed transaction.
Alas, some older software is not aware of KTM and may invoke MSDTC when enlisting in a transaction beyond its local scope.