跨多个 HTTP 请求拆分的多步数据库事务答案

【问题标题】：Multi-step database transaction split across multiple HTTP requests跨多个 HTTP 请求拆分的多步数据库事务
【发布时间】：2011-10-25 12:03:49
【问题描述】：

我过去曾在桌面客户端应用程序中使用 TransactionScope 来回滚不完整的多步骤事务。这种方法似乎不太可能在 Web 应用程序中工作。

如果整个过程未完成，任何人都可以建议如何确保跨多个页面的多个步骤回滚？（例如，他们的浏览器崩溃或在中间过程中关闭浏览器）

当然，我可以写入某种临时表，然后在单个事务中将最终记录传输到真实表，但这存在竞争条件的风险。我想开始一个事务，服务几个页面，每个页面将一段事务写入表，然后通过提交完成事务，如果事务未完成，则回滚时会话结束。

还是我的想法不对？建议？

由于我使用的是 MVC 3、EF 4.1 和 Ninject，我不确定这将如何影响解决方案，但我想我会包含这些信息。

【问题讨论】：

【解决方案1】：

您可能会考虑设置 nservicebus 或 masstransit 并使用他们的传奇设施。

【讨论】：

一个服务总线似乎是多余的，因为我也在使用一个做服务定位的 IoC。
@Mystere 这没有任何意义。服务巴士与国际奥委会非常不同。 Sagas 将消除您的竞争条件并允许非常明确的状态转换（消息）。但是，您可能只需使用临时表就可以逃脱。

【解决方案2】：

没有跨多个页面的数据库事务/TransactionScope。即使尝试做这样的事情也是非常错误的。

你有两种选择来解决这个问题：

使用Session

仅当用户完成所有步骤并确认保存后，才将数据存储在会话中并将其保存到数据库中。这绝对是你需要的。]
使用工作流基础和长期运行的事务。

长时间运行的事务不是数据库事务 - 它们是完全自定义的解决方案，您必须手动实施补偿（长时间运行的事务回滚）。您仍然必须以某种方式检测您的工作流程是否应该得到补偿，但这对于您的解决方案不是必需的。它适用于您需要多个会话的“事务”的解决方案。

【讨论】：

这意味着你必须手动处理并发。这对我来说似乎是一种代码味道。
在 Web 应用程序中手动处理并发是很常见的。数据库事务应该尽可能短——在最常见的场景中只有几分之一秒。你想要做的意味着在数据库中密集锁定几分钟 = 你的应用程序将执行得非常糟糕。