多步数据库事务跨多个HTTP请求拆分 [英] Multi-step database transaction split across multiple HTTP requests

问题描述

我用的TransactionScope在过去与桌面客户端应用程序回滚一个不完整的多步骤交易。这种办法似乎不太可能在Web应用程序中工作。

I have used TransactionScope in the past with desktop client applications to roll back an incomplete multi-step transaction. That approach would seem unlikely to work in an Web application.

人能否提供，其中多个台阶，穿过多个页面，能够确保回滚如果整个处理未完成的方式？ （浏览器崩溃或关闭他们在中间过程例如浏览器）

Can anyone suggest ways in which multiple steps, across several pages, can be ensured to roll back if the entire process is not completed? (their browser crashes or they close the browser in mid process for example)

当然，我会写信给某种形式的临时表，然后在一个事务中的最后记录传送到真正的表，但运行的竞态条件的风险。我想开始事务，服务多个页面，每个页面写一块交易的表（多个），然后用提交完成交易，并且如果没有完成该交易，然后将其回退时在会话结束。

Certainly, i could write to a temp table of some sort, then transfer the final record to the real table in a single transaction, but that runs the risk of race conditions. I'd like to begin a transaction, serve several pages, each page writing a piece of the transaction to the table(s), then completing the transaction with a commit, and if the transaction is not completed, then it is rolled back when the session ends.

还是我没有想到的正确方法？建议？

Or am i not thinking the right way? Suggestions?

由于我使用MVC 3，EF 4.1和Ninject，我不知道怎么会影响解决方案，但我想我会包括这些信息。

Since i'm using MVC 3, EF 4.1 and Ninject, i'm not sure how that will affect the solution, but i thought i'd include that information.

推荐答案

有横跨几页没有数据库事务/ 的TransactionScope 。甚至试图做这样的事情是极其错误的。

There is no database transaction / TransactionScope across several pages. Even trying to do something like that is terribly wrong.

您有两个选项来解决这个问题：

You have two options to solve the problem:

• 使用会话

在会话中存储数据且仅当用户完成所有步骤，并确认其保存持久化到数据库中。这绝对是你所需要的。]

Store your data in session and persist it to the database only if user completes all of the steps, and confirms the save. This is definitely what you need.]

使用工作流程的基础和长期运行的事务。

Use workflow foundation and long running transactions.

长期运行的事务不是数​​据库事务 - 他们是，你必须手动实现（长期运行的事务回滚）补偿完全定制的解决方案。你仍然必须以某种方式检测到您的工作流程应该获得赔偿，但是这是没有必要为您的解决方案。它是在你需要多个会话事务的解决方案。

Long running transactions are not database transactions - they are a completely custom solution where you must implement compensation (rollback of long running transactions) manually. You still have to detect somehow that your workflow should be compensated, but this is not necessary for your solution. It is for a solution where you need a "transaction" for multiple sessions.

这篇关于多步数据库事务跨多个HTTP请求拆分的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！