TransactionScope如何保证跨多个数据库的数据完整性?

发布于 2024-08-24 10:44:33 字数 729 浏览 7 评论 0原文

有人能告诉我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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

万劫不复 2024-08-31 10:44:33

如果它检测到多个数据库将每个范围用作两阶段提交的一部分,则会将其提升为分布式事务协调器 (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.

撕心裂肺的伤痛 2024-08-31 10:44:33

对于分布式事务,实际上可能会发生数据库不一致的情况。你说:

在某些时候,两个数据库都必须
被告知应用他们的更改。让我们
说之后停电了
告诉第一个数据库申请,然后
数据库不同步。或者我是
缺少什么吗?

你不是。我认为这被称为将军问题。事实证明,这是无法阻止的。然而,失败的窗口很小。

With distributed transactions it can in fact happen that the databases become inconsistent. You said:

At some point both databases have to
be told to apply their changes. Lets
say there is a power outage after
telling the first db to apply, then
the databases are out of sync. Or am I
missing something?

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文