我一直在研究 NHibernate for ASP.Net 应用程序（Webforms）的事务管理。我发现的大多数文章都倾向于支持按请求事务处理的方法。虽然我了解每个请求的会话，并且完全赞成它。但是，我并不完全理解每个请求的事务背后的原因。
我的应用程序使用版本字段进行并发检查。如果抛出了一个问题，比如 StaleObjectException，或者其他任何东西，一旦你调用Transaction.Commit(). 我的问题是，如果这是在请求的末尾，你不能轻易知道哪个方法实际上有问题的代码，并且很难从问题中回滚。
例如，在 StaleObjectException 中，通常只需使用更新的数据重新运行该方法。
关于此的任何想法，以及交易管理的任何实践？根据业务逻辑，我倾向于支持尽可能多的交易。多个事务的问题是实际开始/结束事务的位置。
当您退后一步并考虑 Web 应用程序的底层性质时，按请求事务处理范式是有意义的。它是一个请求/响应系统，仅此而已。用户提交对“某事”的请求，应用程序将其转换为执行一个动作或一系列动作，然后应用程序向用户发送响应以指示其当前更新的状态。
在此模型中，对应用程序的每个操作请求都可以（可以说应该）是原子的。毕竟，从用户的角度来看，概念上发生错误时失败是什么？请求失败。发生此类故障时，应用程序应以两种方式响应：
回滚与处理请求相关的任何部分更改，以便持久化数据不会处于“部分”或“未定义”状态。
通知用户（在响应中）请求以某种方式失败。
我的问题是，如果这是在请求的末尾，你不能轻易知道哪个方法实际上有问题的代码，并且很难从问题中回滚。
你能用代码展示一个例子吗？我想知道这个问题是否可以通过应用程序设计的其他元素而不是事务结构来解决。也许请求的处理不是适当的原子或封装。
（评论表明以下可能是个人观点，是NHibernate的正常行为）
例如，在 StaleObjectException 中，通常只需使用更新的数据重新运行该方法。
虽然我当然不是 NHibernate 方面的专家，但我不愿理解这里所说的内容。通常，当异常发生时，简单地“重试”通常不是处理异常的好方法。