你们是否遇到过去银行取款机取款的时候被扣除钱但是没有吐钱的情况.我没有遇到过这种情况，但是我听说有人遇到这种情况。
外行人看热闹，内行人看门道，一般人骂银行不负责任,咱们是搞开发的，就从开发角度分析这个问题.
其实这涉及到一个物理事务问题。通常的事务是基于数据逻辑上的，我们可以使用普通的提交 回滚方式处理它.例如转账一个减去100元，一个加上100元，提交，回滚保证它们同时进行。
但是当涉及到物理方面效果的时候就不是这么简单了，比如取款行为由下面2个事件组成:
(1)取款机吐出100元.
(2)扣除100元
假如执行过程是先1后2
第二个当然能够像普通情况下进行提交和回滚，但是关键在于第一点，那是物理效果，所谓的生米煮成了熟饭是无法被改变的。当钱被用户取走的时候，你怎么回滚?让取款机变成机器人从用户手中抢回钱?如果不回滚的话那么结果就是银行损失了100元。
当然银行喜欢调换一下顺序，变成了:
(1)扣除100元
(2)取款机吐出100元
好了取款机扣除了100元，实打实的再吐钱，对于银行那是当然没有问题了，对于用户就不妙了，如果执行了第一条，取款机突然发生故障，怎么保证第二条也被执行.
当然对于中国的一些银行来说它们的利益是必须被得到保证的，很多自然是选择了第二种顺序.不过这个顺序问题也看出了银行的态度问题，对自己责任和用户利益地对待问题。
那么怎么解决呢。我觉得没有办法完全解决这个问题，因为这个涉及到物理问题，外部物理世界是你不能改变的.
但是可以尽量减少问题发生。怎么办呢?关键在于吐出钱的过程,因为取款需要数钱需要一个时间过程，操作数据库也需要时间。不过提交事务也许不需要长时间，至少单独提交事务比执行后提交时间短，如果我们先扣钱但是不提交扣钱事务，然后吐钱，这个时候要卡住钱，用户看得见钱，但是不能取钱，只有系统提交数据改变以后，取款机才能放手。这个过程唯一有可能出错的地方就是当吐出钱以后如果断电怎么办，关键是否还能卡住钱，如果取款机松手，那么如果没有提交数据银行损失，如果取款机不松手，银行提交数据之后用户损失，感觉后者发生在最后一步，概率小，但是从责任公平角度应当由银行设计系统承担前者情况的风险.