与现实世界事件相对应的数据库事务是否可以实现完美的数据完整性?

发布于 2024-11-18 05:25:59 字数 426 浏览 3 评论 0原文

我正在和一个正在使用 ATM 的人交谈,当 ATM 崩溃时(显然运行的是 Windows XP)并拿走了他的钱。

具有预写日志功能的事务数据库可以确保您的数据库保持一致的状态,即使 ATM 崩溃(即您始终知道 ATM 和客户帐户中应该有多少钱)。然而,发放现金不仅仅是数据库事务,也不是即时操作,因此您应该在发放现金之前还是之后提交交易?在这两种情况下,如果 ATM 在正确的时间崩溃,银行或客户都可能遭受损失。

这个问题有完美的(或者至少相当完美的)解决方案吗?

我能想到的一种方法是,ATM 是否有能力计算里面的钱数。如果 ATM 首先提交交易,然后分配现金,那么在从崩溃中恢复后,ATM 可以立即分配超出根据保证一致的数据库应包含的任何额外资金。

但从硬件的角度来看,我不知道这是否真的可行。

你怎么认为?还有其他方法可以解决这个问题吗?

I was talking to a guy who was using an ATM when it crashed (it was running Windows XP, apparently) and took his money.

A transactional database with write-ahead logging can ensure that your database remains in a consistent state, even if the ATM crashes (i.e. you will always know how much money should be in the ATM and in the customer's account). Dispensing cash, however, is not just a DB transaction and is not an instant operation, so should you commit the transaction before or after the cash is dispensed? In both cases, it is possible for either the bank or the customer to lose money if the ATM crashes at the right time.

Are there any perfect (or at least reasonably perfect) solutions to this problem?

One way I can think is if the ATM had the capability to count the amount of money in it. If the ATM committed the transaction first and then dispensed the cash, then upon recovering from a crash, the ATM could immediately dispense any additional money above what it should contain according to the guaranteed consistent database.

But from a hardware standpoint I don't know if that would really be feasible.

What do you think? Are there any other ways to deal with this issue?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(1

醉城メ夜风 2024-11-25 05:25:59

如果事务内存在数据库系统之外的活动,则使用“状态”列构建“手动事务”是这种情况的解决方案。

例如:
分配缓存状态:

0 - Check the account of user
1 - Check passed, dispensing cache
2 - Dispense cache sucessfully
-1 - Updated status after reboot the ATM from crash if the status is 1
-2 - Updated status after reboot the ATM for other erratic situations ...

您可以设计更多状态来描述困难的崩溃情况。

If there is an activity outside the database system within a transaction, using "status" column to build a "manual transaction" is a solution for such situation.

for example:
Dispense Cache Status:

0 - Check the account of user
1 - Check passed, dispensing cache
2 - Dispense cache sucessfully
-1 - Updated status after reboot the ATM from crash if the status is 1
-2 - Updated status after reboot the ATM for other erratic situations ...

You may design more status to describe the difficult crash situation.

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