我正在向数据库提交事务。如果客户端在交易过程中失去wifi连接，但在提交后，它将不知道交易完成。问题是，只有在移动应用程序同意并且服务器知道1(移动应用程序已经同意并且2(移动应用软件知道交易已经完成的情况下，服务器才应该永久提交交易。解决方案似乎是让移动应用程序发送一条确认消息，确认交易，但如果在服务器上收到确认后，但在服务器发回200之前发生断开连接问题，该怎么办？现在服务器认为移动应用程序知道，但移动应用程序不确定服务器是否收到了此消息。这几乎像是某种类型的握手，因为双方都必须知道对方在做什么。问题是如何在不可靠的网络中处理事务，在这种网络中，服务器需要知道客户端既接受事务，又知道事务已经完成，然后才能使事务永久化。
这是一个两个将军的问题，因此无法解决。确认的确认只是另一条需要确认的消息，因此，在有限的时间内，你永远不会完全确认原始消息已经发送，双方都知道这一点。
在实际生活中，你将不得不选择你接受的风险类型。对于低风险的信息，比如朋友同意见面，一个确认回复通常就足以让他们继续发送，尽管回复可能从未真正通过。现在考虑通过基于GPRS的EDC进行支付。总有一种可能性是，在完全交付付款指令后，连接就断了，而在客户决定离开之前，连接就没有回来。如果没有打印确认收据，商店通常会将付款视为从未完成，只会在稍后恢复交易。商店和顾客都接受这种风险。
在设计你的系统时，"你的咖啡店不使用两阶段提交"这篇文章是一篇非常好的读物。考虑需求。回滚是否不可接受？是否存在某种程度的可容忍甚至可预期的不一致？也许你甚至可以减少客户端的角色，只尝试发送命令，然后从服务器上读取，放弃它自己的命令。