我一直在为NHibernate for ASP.Net应用程序（Webforms）进行事务管理方面的研究。我发现的大多数文章都倾向于按请求进行事务处理。虽然我了解每次请求的会话，但我完全赞成。但是，我不完全了解每次请求交易背后的原因。
我的应用程序使用版本字段进行并发检查。如果引发了诸如StaleObjectException之类的问题或其他任何问题，则在调用Transaction.Commit()后将引发该问题。我的问题是，如果这是在请求末尾，则您将不容易知道哪个方法实际存在有问题的代码，并且很难从该问题回滚。
例如，在StaleObjectException中，通常只需要使用更新的数据重新运行该方法。
有什么想法和交易管理的实践吗？基于业务逻辑，我倾向于支持尽可能多地打开事务。多个事务的问题是实际开始/结束事务的位置。
最佳答案
当您退后一步并思考Web应用程序的基本特性时，按请求事务的范例就很有意义。这是一个请求/响应系统，仅此而已。用户提交对“某物”的请求，应用程序将其转换为执行一个动作或一系列动作，然后该应用程序向用户发送响应以指示其当前更新状态。
在此模型中，对应用程序的每个操作请求都可以（可以说）是原子的。毕竟，从用户的角度来看，从概念上讲，发生错误时什么会失败？请求失败。在发生此类故障时，应用程序应以两种方式响应：
回滚与处理请求相关的任何部分更改，以使保留的数据不会处于“部分”或“未定义”状态。
通知用户（在响应中）请求以某种方式失败。
我的问题是，如果这是在请求末尾，则您将不容易知道哪个方法实际存在有问题的代码，并且很难从该问题回滚。
你能用代码展示一个例子吗？我想知道问题是否可以由应用程序设计中的其他元素（而不是事务结构）解决。也许对请求的处理不是正确的原子性或封装性。
（评论表明，以下内容可能是更多个人观点，是NHibernate的正常行为）
例如，在StaleObjectException中，通常只需要使用更新的数据重新运行该方法。
虽然我当然不是NHibernate的专家，但我还是很犹豫，以了解这里所说的话。通常，发生异常时，简单地“重试”通常不是处理异常的好方法。
关于c# - asp.net WebForms中的nhibernate事务管理，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/11914508/