nhibernate 和嵌套事务
我知道 nhibernate 不支持嵌套事务。
假设我得到了这样的东西:
- UserService.BeginTransaction (on current session)
- UserService.Save
- UserService->FeedService
- FeedService.BeginTransaction(在当前会话中)
- FeedService.Save
- FeedService.Commit(在 #3.1 中返回的事务上)
- UserService->AddressService
- AddressService.BeginTransaction(在当前会话中)
- AddressService.Save
- AddressService.Commit(在 #4.1 中返回的事务上)
- UserService.Commit(在 #1 中返回的事务上)
在 #3.3 中调用 commit 时会发生什么交易已提交?我需要一切才能成功或失败。
I know that nhibernate doesnt support nested transactions.
Let's say that I got something like this:
- UserService.BeginTransaction (on current session)
- UserService.Save
- UserService->FeedService
- FeedService.BeginTransaction (on current session)
- FeedService.Save
- FeedService.Commit (on the returned transaction in #3.1)
- UserService->AddressService
- AddressService.BeginTransaction (on current session)
- AddressService.Save
- AddressService.Commit (on the returned transaction in #4.1)
- UserService.Commit (on the returned transaction in #1)
What happens when commit is invoked in #3.3, is the transaction commited? I need everything to either succeed or fail.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
正如 Jamie 所说,交易应该在更高的层面上进行管理,以避免出现这种情况。
但是,如果您出于某种原因必须将开始/提交保持在“服务”级别,则可以将所有内容包装在
TransactionScope
中,您将完成()
只有在一切成功之后。As Jamie said, transactions should be managed at a higher level to avoid this situation.
However, if you must keep the begin/commit at the "Service" level for whatever reason, you could wrap everything in a
TransactionScope
, which you'llComplete()
only after everything suceeds.是的。 3.1 中的 BeginTransaction 调用不会执行任何操作,因为已经存在一个活动事务。如果您希望所有操作参与同一事务,则不要在 3.x 和 4.x 中调用 Begin/End Transaction。
我的建议是不要在服务或存储库类中使用事务。我要么在 UI 级别控制事务,要么创建一个封装业务流程的类。
Yes. The BeginTransaction call in 3.1 won't do anything because there is already an active transaction. If you want all of your operations to participate in the same transaction then don't call Begin/End Transaction in 3.x and 4.x.
My advice is to not use transactions in service or repository classes. I either control the transaction at the UI level or create a class that encapsulates the business process.