银行存钱悖论探讨！！（慎入，逻辑混乱，请看完所有楼再回帖以免越弄越乱）

mike79

原帖由 冬瓜头 于 2010-1-11 23:22 发表
commit成功的消息到达了应用服务器的tcp协议栈缓存中，并且tcp成功的返回了一个珍贵的ack应答，数据库服务器还没收到这个ack呢，便Down机了，或者收到ack了，正要往日志里更新commit成功点了，Down机了

为什么牵扯到网络协议？
应用服务器：
向数据库发送以下两条sql语句
update xxx set 余额=余额+5;
commit;
然后就等待数据库的通知

数据库服务器：
执行那两条sql语句
通知应用服务器执行完成

对于数据库来说只要commit返回成功，余额就更改了。

mike79

原帖由 冬瓜头 于 2010-1-12 08:57 发表
不管是哑终端还是智能终端，哑终端就能避免这个问题了么？请教楼上怎么避免的呢？


有人在另一个论坛说："或者收到ack了，正要往日志里更新commit成功点了，Down机了" 这个不可能，数据库把commit写入日至之 ...

在逻辑上update和commit是原子操作，不能分割的。
我觉得你对数据库事务的理解有偏差。

冬瓜头

为什么不能牵扯网络协议，ack是要传的。原子操作逻辑transaction之类都是上层的，从上层角度来讲，确实是没问题，但是到了底层就不同了，mike79能否列一下从上层到底层整个过程，不要只看上层逻辑，如果能指出我那个场景中哪一步有问题，不胜感激。

mike79

数据库服务器成功的将记录更新到了磁盘并且受到了文件系统成功写入的应答，该回复应用服务器成功的消息了，
-------------------------------------------------------------------------
update操作之后数据库并不认为事务已经提交，余额没有变化。如果你通过其他的数据库会话查询余额的话余额还是原来的。
只有等commit操作之后余额才+5，通过其他数据库会话查询的话会发现余额变了。

ps 数据库事务和传输协议之间没关系的。

冬瓜头

请看原文第二行，“并且commit”。我们在此对于数据库上层逻辑的认识是一致的。数据库上层逻辑是与外部无关，但是与app通信时候，怎么可能无关，app与终端通信时，更有关系，事物成功与否，是要体现在操作终端的，只有终端认为我存款成功我才能走人啊。

mike79

在update之后，commit之前，其他数据库会话查询余额时，即使物理文件上余额已经变化，但是这些会话发现这个事务没有提交，也不会读取物理文件上的余额。而是查询原来的值。对于某些数据库实现，这些查询会话会被挂起，直到update操作commit或者rollback

如果在update之后，commit完成之前数据库崩溃，当数据库重启后会检查发现update操作没有commit，数据库自动rollback。也就是说即使物理文件上的余额已经变化，此时也会恢复到原来的值。

mike79

原帖由 冬瓜头 于 2010-1-11 23:22 发表
并且commit。数据库服务器成功的将记录更新到了磁盘并且受到了文件系统成功写入的应答，该回复应用服务器成功的消息了，commit成功的消息到达了应用服务器的tcp协议栈缓存中，并且tcp成功的返回了一个珍贵的ack应答，数据库服务器还没收到这个ack呢，便Down机了，或者收到ack了，正要往日志里更新commit成功点了，Down机了。

你这个commit是什么意思？是数据库层面的commit，也就是说数据库commit完成？
commit成功，事务提交，余额就永久改变了。这个和应用服务器是否收到数据库的返回没有关系。
而且你前面说“commit成功的消息到了应用服务器”，后面又说“正要往日志里更新commit成功点了，Down机了。”这两个是矛盾的。如果日志里面没有记录commit点的话，数据库是不会返回commit成功的。

mike79

原帖由 冬瓜头 于 2010-1-12 11:17 发表
请看原文第二行，“并且commit”。我们在此对于数据库上层逻辑的认识是一致的。数据库上层逻辑是与外部无关，但是与app通信时候，怎么可能无关，app与终端通信时，更有关系，事物成功与否，是要体现在操作终端的 ...

假设数据库commit之后，还没能返回给应用服务器就崩溃了，那么应用服务器还是等待。你就会发现响应特别慢，可能最终超时了，你可能认为钱没有存入。
数据库重启后，柜台给你作个查询，发现余额已经增加了。接下来的操作就是业务上的了，比如说给你补单子之类的，这个和数据库就没什么多大关系了。

我觉得你好像认为数据库事务的结束要到应用服务器接收到数据库的返回才算？不是这样的。

冬瓜头

我说的commit是指应用向数据库发起commit，而数据库并未commit完成，这之间的状态。
“如果日志里面没有记录commit点的话，数据库是不会返回commit成功的”，好的，这一点我理解并且同意。那么能否请看一下7楼的分析，这时候也有问题。

冬瓜头

“你可能认为钱没有存入。
数据库重启后，柜台给你作个查询，发现余额已经增加了。”

问题就在这里，如果操作员没有关注余额呢？咱们这里不谈人为控制，不一定每个操作员都记得看余额。
如果没有回执单的应用呢？如果没有很深的人为介入呢？比如某客户关系管理系统，操作员录入了客户信息，提示成功了，回头一查，没了，但是自己又没注意到，把报表打出来，boss一看怎么那个大客户没在里面，人家下的单也进不来，公司损失了几千万。。。