Home/ Questions/Q 6126119
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T16:19:55+00:00

I was talking to a guy who was using an ATM when it crashed

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0