TransactedReceiveScope - 事务何时提交?

发布于 2024-10-18 12:07:21 字数 542 浏览 2 评论 0原文

场景:

我们有一个 wcf 工作流程,其客户端不使用事务流。 该工作流包含多个连续的 TransactedReceiveScope(使用基于内容的关联)。 TransactedReceiveScopes 包含自定义数据库操作。

观察:

当我们针对第一个调用运行 SQL 分析器时,我们会在配置文件跟踪中看到所有自定义数据库调用和 SaveInstance 调用。

我们注意到,即使 SendReply 位于 TransactedReceiveScope 的最末尾,有时 sendreply 也会在事务提交前 10 秒发生。

我们尝试将 TimeToPersist 和 TimeToUnload 更改为零,但这没有效果。 (跟踪显示 SaveInstance 无论如何都会立即发生,但提交似乎被延迟了)。

问题:

我们的观察正确吗?

交易在什么时候提交?这是否像垃圾收集 - 即它会在不忙的时候提交?

有什么方法可以控制提交延迟,或者是使用来自客户端的事务流来做到这一点的唯一方法(然后它应该在客户端提交时全部提交,包括持久)。

Scenario:

We have a wcf workflow with a client that does NOT use transactionflow.
The workflow contains several sequential TransactedReceiveScopes (using content-based correlation).
The TransactedReceiveScopes contain custom db operations.

Observations:

When we run SQL profiler against the first call, we see all the custom db calls, and the SaveInstance call in the profile trace.

We've noticed that, even though the SendReply is at the very end of TransactedReceiveScope, sometimes the sendreply occurs a good 10 seconds before the transaction gets committed.

We tried changing the TimeToPersist and TimeToUnload to zero, but that had no effect. (The trace shows the SaveInstance happening immediately anyway, but rather the commit seems to be delayed).

Questions:

Are our observations correct?

At what point is the transaction committed? Is this like garbage collection - i.e. it commits some time later when it's not busy?

Is there any way to control the commit delay, or is the only way to do this to use transactionflow from the client (anc then it should all commit when the client commits, including the persist).

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

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

发布评论

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

评论(1

破晓 2024-10-25 12:07:21

TransactedReceiveScope 在主体完成时提交事务,但所有执行都是通过调度程序完成的,这可能会在一段时间后完成。它与垃圾收集无关,并且除了避免繁忙的机器和也可能在执行队列中的许多其他并行活动之外,没有真正的方法可以影响它。

The TransactedReceiveScope commits the transaction when the body is completed but as all execution is done through the scheduler that could be some time later. It is not related to garbage collection and there is no real way to influence it other that to avoid a busy machine and a lot of other parallel activities that could also be in the execution queue.

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