TransactionScope如何保证跨多个数据库的数据完整性?
有人能告诉我TransactionScope如何保证跨多个数据库的数据完整性的原理吗?我想它首先将命令发送到数据库,然后等待数据库响应,然后向它们发送消息以应用之前发送的命令。然而,当发送这些应用消息时执行突然停止时,我们仍然可能会得到一个已应用该命令的数据库和一个未应用该命令的数据库。有人能解释一下吗?
编辑:
我想我要问的是,在断电或突然关闭的情况下写入多个数据库时,我是否可以依靠 TransactionScope 来保证数据完整性。
谢谢,巴斯
示例:
using(var scope=new TransactionScope())
{
using (var context = new FirstEntities())
{
context.AddToSomethingSet(new Something());
context.SaveChanges();
}
using (var context = new SecondEntities())
{
context.AddToSomethingElseSet(new SomethingElse());
context.SaveChanges();
}
scope.Complete();
}
Can someone tell me the principle of how TransactionScope guarantees data integrity across multiple databases? I imagine it first sends the commands to the databases and then waits for the databases to respond before sending them a message to apply the command sent earlier. However when execution is stopped abruptly when sending those apply messages we could still end up with a database that has applied the command and one that has not. Can anyone shed some light on this?
Edit:
I guess what Im asking is can I rely on TransactionScope to guarantee data integrity when writing to multiple databases in case of a power outage or a sudden shutdown.
Thanks, Bas
Example:
using(var scope=new TransactionScope())
{
using (var context = new FirstEntities())
{
context.AddToSomethingSet(new Something());
context.SaveChanges();
}
using (var context = new SecondEntities())
{
context.AddToSomethingElseSet(new SomethingElse());
context.SaveChanges();
}
scope.Complete();
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果它检测到多个数据库将每个范围用作两阶段提交的一部分,则会将其提升为分布式事务协调器 (msdtc)。 每个范围都投票提交,因此我们获得了 ACID 属性,但分布在数据库中。它还可以与TxF、TxR集成。您应该能够按照您描述的方式使用它。
这两个数据库是一致的,因为在 MTC 下运行的分布式 COM+ 事务已附加到它们,即数据库事务。
如果一个数据库投票同意提交(例如,通过执行 (:TransactionScope).Commit()),“它”会告诉 DTC 它投票同意提交。当所有数据库都完成此操作后,它们就会有一个更改列表。只要数据库事务现在不死锁或与其他事务冲突(例如,通过抢占一个事务的公平算法),每个数据库的所有操作都在事务日志中。如果系统在一个数据库的提交尚未完成但另一个数据库的提交已完成时断电,则事务日志中已记录所有资源都已投票同意提交,因此不存在提交失败的逻辑含义。因此,下次无法提交的数据库启动时,它将完成处于不确定状态的那些事务。
It promotes it to the Distributed Transaction Coordinator (msdtc) if it detects multiple databases which use each scope as a part of a 2-phase commit. Each scope votes to commit and hence we get the ACID properties but distributed accross databases. It can also be integrated with TxF, TxR. You should be able to use it the way you describe.
The two databases are consistent as the distributed COM+ transaction running under MTC have attached to them, database transactions.
If one database votes to commit (e.g. by doing a (:TransactionScope).Commit()), "it" tells the DTC that it votes to commit. When all databases have done this they have a change-list. As far as the database transactions don't deadlock or conflict with other transactions now (e.g. by means of a fairness algorithm that pre-empts one transaction) all operations for each database are in the transaction log. If the system loses power when not yet commit for one database has finished but it has for another, it has been recorded in the transaction log that all resources have voted to commit, so there is no logical implication that the commit should fail. Hence, next time the database that wasn't able to commit boots up, it will finish those transactions left in this indeterminate state.
对于分布式事务,实际上可能会发生数据库不一致的情况。你说:
你不是。我认为这被称为将军问题。事实证明,这是无法阻止的。然而,失败的窗口很小。
With distributed transactions it can in fact happen that the databases become inconsistent. You said:
You aren't. I think this is known as the generals problem. It can provably not be prevented. The windows of failure is however quite small.