asp.net WebForms 中的休眠事务管理答案

【问题标题】：nhibernate transaction management in asp.net WebFormsasp.net WebForms 中的休眠事务管理
【发布时间】：2012-08-08 12:19:59
【问题描述】：

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

我的应用程序使用版本字段进行并发检查。如果出现问题，如 StaleObjectException 或其他任何问题，则在您调用 Transaction.Commit() 时会引发此问题。我的问题是，如果这是在请求的末尾，你不能轻易知道哪个方法实际上有问题的代码，并且很难从问题中回滚。

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

对此有何想法，以及交易管理的任何实践？根据业务逻辑，我倾向于支持尽可能多的交易。多个事务的问题是实际开始/结束事务的位置。

【问题讨论】：

【解决方案1】：

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

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

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

（评论表明以下可能是个人观点，是NHibernate的正常行为）

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

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

【讨论】：

是的，它被标记为“异常”，这是一个详细说明由于乐观并发导致的不匹配的异常。发生这种情况时，大多数情况下您可以通过重新运行查询轻松“修复”错误。 StackOverflow 上的这个问题可能会让您对 NHibernate 在乐观并发/版本检查方面的工作方式有所了解 (stackoverflow.com/questions/8409146/…)。因此，对于这种情况，在 Page_EndRequest 状态下引发错误是没有意义的。
@KarlCassar：很公平，但如果有的话，它只会加深我对大多数框架的厌恶。任何时候响应是“哦，这个框架有时会发生。你只需要记住做其他非标准的事情，它可能会没事的”，然后我觉得框架在某种程度上失败了。当然，我并不期望任何代码都是完美的。但是，如果某个特定的库要求我使用其他不好的做法才能使用它，我可能不会使用它。但这只是个人意见，超出了问题的范围，真的:)
这是一种不好的做法，如果您选择使用乐观并发检查，如何以更好的方式克服这种“异常”？