mysql - 工作单元的副作用可以用 TransactionScope 修复，但不适用于 MySql.Data

Question

我将 NHibernate 与 MySql.Data ADO 连接器一起使用。

我有带有 CRUD 方法的 Dao 类:创建、更新、删除。

这些方法打开它们自己的 NHibernate 事务并提交它们。

现在我正在更改我的设计以使用工作单元模式。 session 和事务将在上层打开和提交，而不是在 Dao 方法中。所以我必须从 Dao 类中删除提交。

我发现这种方法有几个问题:

• 我在 commit() 点捕获了数据库特定的异常。现在提交在上面的层中完成。所以我必须将所有特定于数据库层的代码添加到外层吗？诸如捕获 FK 违规或 NH 特定异常之类的事情。
• 我将同时获得所有可能的异常，必须辨别它们来自哪个具体的 Dao 类，并实现代码来处理它们。
• 如果其中一个步骤失败，我将无法中止操作，因为直到最终提交完成我才知道。我知道事务回滚会防止数据不一致，但是仅仅因为我不知道前面几行导致了错误，运行下面所有的代码似乎是一种性能浪费。

我不喜欢这种后果。我希望我可以在事务范围内使用嵌套事务，这样我就可以在本地进行提交，但似乎 MySql.Data 连接器不支持它们。我试过了，但有异常(exception):

System.InvalidOperationException : Nested transactions are not supported

是否有任何解决方法可以让我在插入、更新或删除操作完成时获得可能的异常？ session.Flush() 会这样做吗？或者有什么方法可以将 TransactionScope 与 MySql.Data 一起使用？

如果这个问题看起来很幼稚，我很抱歉，但我已经用谷歌搜索了一段时间，但没有找到任何明确的解决方案。关于不使用MySql.Data的事务范围，我得到的所有信息似乎都有些陈旧，我不确定现在是否真的无法完成。

Answer 1

最后我决定在任何时候使用嵌套事务 Commit() 时使用 Flush()。它似乎工作正常，我在那一刻得到了异常，我能够在本地处理它们。

我知道 NHibernate 的最佳实践包括不要如此随意地使用 Flush()，但就 MySql 和 NHibernate 的嵌套事务不可用而言，我没有找到更好的解决方案，所以这似乎是较小的邪恶。