使用 SQL Server Service Broker 在 .NET 应用程序之间进行消息传递

发布于 2024-12-11 05:50:45 字数 333 浏览 0 评论 0原文

我正在考虑使用 Service Broker 在两个 .NET 应用程序之间进行消息传递,其中一个应用程序需要可靠地向另一个应用程序发送消息。对于发起者方面的情况,我有一个很好的想法。

但是,消费者应用程序需要从队列加载消息,进行一些处理,然后确认处理顺利。处理可能会失败,在这种情况下我需要重试该消息。我还需要保留所有已出于历史目的而处理的消息。

据我所知,当我执行 RECEIVE 时,该消息将从队列中删除。那么,如果出现故障,消费者应用程序应该怎么做?再次将消息推送到队列中?我可以将消息标记为“正在处理”,然后在任务成功完成后将其删除吗?

我如何使用 Service Broker 对此进行建模?

I am considering using Service Broker for messaging between two .NET apps, where one app needs to reliably send messages to the other. I have a pretty good idea on how this looks at the initiator side.

However, the consumer app needs to load messages from the queue, do some processing, and then acknowledge that processing went well. The processing might fail, in which case I need to retry the message. I would also need to keep all messages that has been processed for history purposes.

As far as I can tell, the message is removed from the queue when I do a RECEIVE. So what should the consumer app do in case of a failure ? Push the message onto the queue again ? Can I mark a message as "in processing" and then remove it once my task completed successfully ?

How would I model this using Service Broker ?

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

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

发布评论

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

评论(1

∞琼窗梦回ˉ 2024-12-18 05:50:46

您可以在事务内接收并在出现错误时回滚事务。但请注意,内置的有害消息处理将在给定消息进行 5 次此类回滚后禁用队列。

You can receive within a transaction and rollback the transaction in case of error. Beware though that the built-in poison message handling will disable the queue after 5 such rollbacks for a given message.

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