c# - 您可以在 nhibernate 的一个 session 中发生多个事务吗？这是个坏主意吗？

Question

我正在考虑为 NHibernate 持久层制作我自己的 IUnitOfWork 实现。

似乎正确的做法是在构造函数中实例化 ISession 和 ITransaction，然后在析构函数或 Dispose() 方法。

当然，如果有人调用Save() 方法，那么ISession 将被刷新并且ITransaction 将完成，所以在调用 Save() 之后，不会再有一个有效的打开事务到 Save() ......除非我提交第一个事务并立即打开另一个新事务。但这是个好主意吗？

在设计方面，执行一次提交操作是有意义的，但我不一定能控制代码，其他开发人员可能不太遵守 UnitOfWork 模式。

尝试使 UnitOfWork 容忍每个 session 的多个事务，我是否会失去/获得任何东西？我是否应该只检查打开的事务并在已提交的情况下抛出异常，而不是进行新事务？

Answer 1

回答第一个问题:是的，一个 session 中可以有多个事务。

是个好主意吗？这取决于。

问题在于第一个事务中更改的数据将被提交，而不确定整个工作单元( session )是否在最后提交。比方说，当您在稍后的事务中遇到 StaleObjectException 时，您已经提交了一些数据。请注意，这种异常会使您的 session 无法使用，您无论如何都必须销毁它。然后很难重新开始并再次尝试。

我会说，它在这些情况下运作良好:

• 这是一个 UI 应用程序
• 仅在最后一次交易中刷新更改。

UI 应用程序

错误由用户交互处理。这意味着用户可以在出现错误的情况下看到实际存储的内容并重复他所做的更改。

仅在最后一次交易中刷新更改

NH 实现的 session 仅在最后或“必要时”刷新更改。因此，可以在 session 提交之前将更改保留在内存中。问题是 NH 需要在每次查询之前刷新 session ，这很难控制。它可以被关闭，这会导致副作用。在编写简单的事务时，您可能会控制它。在一个复杂的系统中，几乎不可能确保没有任何问题。

简单方法 (tm)

我编写了一个相当大的客户端-服务器系统的持久层。在这样的系统中，您没有用户直接处理错误。您需要处理系统中的错误，并以一致的状态将控制权返回给客户端。

我将整个交易处理简化到绝对最低限度，以使其稳定和“白痴证明”。我总是有一个 session 和一个事务一起创建，它要么被提交，要么不被提交。