c# - asp.net WebForms 中的 nhibernate 事务管理

Question

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

我的应用程序使用版本字段来执行并发检查。如果抛出问题(例如 StaleObjectException 或其他任何问题)，则在调用 Transaction.Commit() 后就会抛出该问题。我的问题是，如果这是在请求的末尾，您无法轻易知道哪个方法实际上存在有问题的代码，并且从问题中回滚非常困难。

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

对此有什么想法以及事务管理的实践吗？我倾向于根据业务逻辑开启尽可能多的交易。多个事务的问题是在哪里实际开始/结束事务。

Answer 1

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

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

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

2. 通知用户(在响应中)请求因某种原因失败。

   My issue is that if this is in the end of request, you cannot easily know which method actually had the problematic code, and it is extremely difficult to rollback from the issue.

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

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

For example, in a StaleObjectException, normally one needs just to re-run the method, with the updated data.

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