asp.net WebForms中的nhibernate事务管理

Question

我一直在研究用于ASP.Net应用程序(Webforms)的NHibernate的事务管理。我发现大多数文章倾向于支持按请求处理事务的方法。虽然我理解session-per-request，并完全支持它。然而，我并不完全理解每次请求事务背后的原因。

我的应用程序使用版本字段进行并发检查。如果抛出一个问题，比如StaleObjectException或其他任何东西，只要调用Transaction.Commit()就会抛出这个问题。我的问题是，如果这是在请求的末尾，您不能很容易地知道哪个方法实际具有有问题的代码，并且很难从问题中回滚。

例如，在StaleObjectException中，通常只需要使用更新后的数据重新运行该方法。

对此有什么想法，有没有事务管理的实践？基于业务逻辑，我倾向于尽可能多地开放交易。多个事务的问题是在哪里实际开始/结束事务。

Answer 1

当您退后一步并思考web应用程序的底层性质时，每请求事务范例是有意义的。它是一个请求/响应系统，仅此而已。用户提交对“某物”的请求，应用程序将其转换为执行一个或一系列操作，然后应用程序向用户发送响应以指示其当前更新的状态。

在此模型中，对应用程序的每个操作请求都可以(可以说)是原子的。毕竟，从用户的角度来看，从概念上讲，当出现错误时，什么东西失败了？请求失败。出现此类故障时，应用程序应以两种方式响应：

1. 回滚与处理请求关联的任何部分更改，以便持久化数据不会处于“部分”或“未定义”状态。

1. 以某种方式通知用户请求已失败(在响应中)。

我的问题是，如果这是在请求的末尾，那么您就不容易知道哪个方法实际具有有问题的代码，并且从问题中回滚是极其困难的。

你能用代码展示一个例子吗？我想知道这个问题是否可以通过应用程序设计的其他元素而不是事务结构来解决。也许请求的处理不是适当的原子或封装。

(评论表明，以下内容可能更多是个人观点，是NHibernate的正常行为)

例如，在StaleObjectException中，通常只需要使用更新后的数据重新运行该方法。

虽然我肯定不是NHibernate方面的专家，但我在理解这里所说的内容时犹豫不决。通常，当异常发生时，简单地“再试一次”通常不是处理异常的好方法。