TransactionScope 的层次结构

发布于 2024-08-03 04:29:31 字数 160 浏览 5 评论 0原文

是否可以有一个事务范围的层次结构?

如果外部事务范围进行了处置,那么内部事务范围中所做的更改会发生什么?

我的特殊问题是我的测试代码运行具有事务范围的代码。当我调用具有事务范围的第二组代码时,我得到“无法访问已处置的对象。事务”。难道处置内层事务范围也在处置外层事务范围吗?

Is it possible to have a hierarchy of transaction scopes?

If the outer transaction scope does a dispose, what will happen to changes made in the inner transaction scope?

My particular problem is that I have test code that runs code that has a transaction scope. When I call a second set of code with a transaction scope I get "Cannot access a disposed object. Transaction". Could it be that the dispose of the inner transaction scope is also disposing the outer transaction scope.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

°如果伤别离去 2024-08-10 04:29:31

我怀疑这就是正在发生的事情。如有必要,只要底层技术支持分布式事务,TransactionScope 就可以嵌套。例如,如果您启动一个事务并更新数据库 A 中的一些数据,然后调用一个函数,并在该函数内创建一个新的 TransactionScope 并将一些数据插入数据库 B 中,则内部事务使用“环境”已经开放的交易。但是,要实现此功能,您需要运行分布式事务协调器(对于 SQL Server)。此外,SQL Server 2005 及更高版本能够将事务作为常规事务启动,并在需要时将其提升为分布式事务,而 SQL 2000 会将所有事务作为分布式事务启动,因为它没有能力推广他们。

当您有嵌套事务时,整个事务只有在最外层事务提交后才会提交。

以下是一些详细信息

看看 TransactionScopeOption;它决定了嵌套事务如何与外部事务交互。

I doubt this is what is happening. TransactionScopes can be nested as long as the underlying technology supports distributed transactions, if necessary. For instance, if you start a transaction and update some data in database A, and then you call a function, and inside that function, you create a new TransactionScope and insert some data into database B, then the inner transaction uses the "ambient" transaction that was already open. However, for this to work you need the Distributed Transaction Coordinator running (for SQL Servers). Also, SQL Server 2005 and above has the ability to start a transaction as a regular transaction and promote it to a distributed transaction if it needs to, whereas SQL 2000 will start all of them as distributed transactions because it doesn't have the ability to promote them.

When you have nested transactions, the whole transaction doesn't commit until the outer-most transaction is committed.

Here's some more info.

Take a look at TransactionScopeOption; that determines how the nested transaction interacts with outer transactions.

别再吹冷风 2024-08-10 04:29:31

当外部事务失败时,所有内部事务都会回滚。如果您提交内部的一个,并处理外部的,内部的仍然会回滚。事实上,除非外部允许它提交,否则内部不会提交。

你正在犯外在的罪,不是吗?请参阅此处了解这方面的好论文。

When an outer transaction fails, all the inner ones will we rolled back. If you commit and inner one, and dispose the outer, the inner still rolls back. In fact the inner doesn't commit unless the outer one lets it by committing.

You are committing the outer one aren't you? See here for a good paper on this.

掩饰不了的爱 2024-08-10 04:29:31

是的,可以有事务范围的层次结构。 这篇博文解释了他们如何工作,特别是应如何实例化内部事务范围以及事务如何完成和处理。犯罪。

重要的是要记住事务和事务范围之间的区别 - 默认情况下(即没有TransactionScopeOption)您只会使用即使您嵌套事务范围,也是单个事务。

关于“已处置”错误消息,请参阅此问题

Yes, it's possible to have a hierarchy of transaction scopes. This blog post explains how they work, in particular how the inner transaction scope should be instantiated and how the transactions complete & commit.

It is important to keep in mind the distinction between transactions and transaction scopes - by default (i.e. in the absense of TransactionScopeOption) you will only utilise a single transaction even when you nest transaction scopes.

Regarding the "disposed" error message, see this question.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文