Perfect data integrity possible with database transactions that correspond to real world events?

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?

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.