原帖由 冬瓜头 于 2010-1-12 14:01 发表 http://bbs.chinaunix.net/images/common/back.gif
“这种前端认为成功，后端最终回滚的情况是不可能出现的。反过来，前端认为操作失败，而后端实际上操作成功的情况倒是有可能的”
那个例子是我说错了。
这个帖子没什么用意，就是探讨一下，数据丢失到底是怎 ...
你总算明白 我说 POS 是什么意思了……
:mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen: :mrgreen:
我依然不懂你说的pos:em16:
数据库commit完成，在回应app端瞬间出现故障，这个情况下 操作员或者比方我们用柜员机等东西的 "人",按照流程在重新可用的时候肯定要查询你的帐户余额的啊！要查询你的操作是否已经完成的啊！
总的来说:数据库中事务完整的完成commit就表明操作已成功，无非就是操作员没有看到最后的一个界面或者回单。
原帖由 wa0362 于 2010-1-12 21:08 发表 http://bbs.chinaunix.net/images/common/back.gif
数据库commit完成，在回应app端瞬间出现故障，这个情况下 操作员或者比方我们用柜员机等东西的 "人",按照流程在重新可用的时候肯定要查询你的帐户余额的啊！要查询你的操作是否已经完成的啊！
总的来说:数 ...
我很纳闷，自动chinaunix跟了It168之后，我用天涯明月刀帐户登录
第二天再打开chinaunix就又变成wa0362账号登录了！ 咋就存的不是天涯明月刀呢？
oracle的commit和我们发帖子时点击的“commit”意思不一样:mrgreen:
原帖由 冬瓜头 于 2010-1-12 16:21 发表 http://bbs.chinaunix.net/images/common/back.gif
我依然不懂你说的pos:em16:
pos的操作只做一个纯粹的 IO终端，所有的事务提交都是在后端，只有 库 同步写完成了，才会给 终端 返回 确定值，数据存储成功是前提……
例子中的终端一词就是指这个啊，不管是智能终端还是io终端。
原帖由 冬瓜头 于 2010-1-11 23:22 发表 http://bbs.chinaunix.net/images/common/back.gif
某日我去银行存捡来的5块钱，操作员拿着我的卡和现金，鄙视的看着我，我没什么感觉，习惯了。当他刷卡之后，点击输入金额5，点击存入之后，数据发送到应用服务器，应用服务器命令数据库服务器将“余额”改为“余额+5”，并且commit。数据库服务器成功的将记录更新到了磁盘并且受到了文件系统成功写入的应答，该回复应用服务器成功的消息了，
先假定银行系统的实际内部细节是如此吧,在你这个基础上来展开讨论。
commit成功的消息到达了应用服务器的tcp协议栈缓存中，并且tcp成功的返回了一个珍贵的ack应答，数据库服务器还没收到这个ack呢，便Down机了，或者收到ack了，正要往日志里更新commit成功点了，Down机了。
你这里讨论的是TCP建立连接的三次握手吧？在你提到的以上场景，两端的Socket都还没有进入ESTABLISHED的状态，应用服务器怎么能够收到“成功”的消息呢？至少要先建立连接，然后才能传输和交互业务数据啊。
应用之间传输信息并交互，对于TCP而言，是建立在连接之上的。
如果你这里是讨论业务处理过程中的问题，那么应用协议必须要有确认报文，而不能只是依赖于底层TCP。
重启之后，当然是将这笔操作回退了，数据文件中的“余额+5”变回了“余额”。
但是就在几分钟之前，应用服务器早就把成功的消息传回给了操作员终端，我也拿着回执单走了。但是我回去一看，怎么余额没有增加？我气冲冲的找到柜台，依然是鄙视的眼光，操作员说：5块钱，至于么！
你提到的这个问题之所以有可能出现，是应用流程设计的问题：
你隐含的操作是数据库先告诉应用系统已经commit成功了然后再写日志。如果业务处理流程真如你前面所言，那么设计者实际上就应该考虑到以上可能存在的不一致的问题，那么先写日志，日志写成功以后再告诉应用不就行了？这个业务流程是你假想的，或者说是你设计的，只能说是设计上有问题。
其实你只要在端到端之间都提供可靠的应用协议，是不可能出现你说的问题。
后台数据库<-------->应用系统<-------->操作员<-------->用户
每一个环节的业务处理流程都有不可靠的因素存在，需要良好的业务设计来满足。
其实你提到的问题其本质不是机器的问题，而是你所假想的流程本身的问题，或者说是人的问题，而不是机器的问题。
[ 本帖最后由 wuqing 于 2010-1-13 08:57 编辑 ]
每一笔交易都有一个唯一标识这笔交易的标志，不管怎么样，都可以用这个唯一标识来做处理，重做，回滚。当然，你说的存钱或取钱的整个流程中也许不是你想象的那样。
感谢48楼关注。tcp连接早已建立了，此时如果连接还没建立，那app如何与db通信呢，应是tcp长连接的。业务层的ack被tcp传过去之后，只要tcp层ack了，那么剩下的就是app的事情了，例子中所想表达就是这之间的状态，目的收到业务层ack了所以显示成功。当然，这个例子流程有错，正如你说的应当是先commit再ack的。后面帖子也更正了，并举了另外的例子。看来这个情况确实存在，而且得需要人为干预才能解决的。