CODEWITHSUNDEEP
nservicebus
Richiban
Richiban

Reputation: 5930

In NServiceBus how can I prevent multiple messages for the same resource being processed concurrently?

We have an NServiceBus endpoint that currently listens for ProductChanged events and communicates a number of these changes to a third party.

Due to the volume of events we need to process we have scaled to multiple nodes with multiple logical processors each, but have started running into an issue where multiple messages referring to the same product are being processed simultaneously and causing conflicts in the third party system.

Up until now we've only made use of the basic messaging features of NServiceBus, what features doesn't have that would allow us to "lock" a particular product ID so that any incoming messages for a product that's currently being processed with either be discarded or queued for a later retry?

Reading https://docs.particular.net/nservicebus/sagas/concurrency it seems that Sagas might be able to do this, but I'm not 100% sure on this and in any case it feels like it might be overkill for this scenario?

We're using SQL transport, NSB v6

Just to clarify the problem: while we're able to process an arbitrary number of messages simultaneously, we must not process two messages with the same product ID simultaneously.

Upvotes: 0

Views: 865

Answers (1)

Sean Feldman
Sean Feldman

Reputation: 25994

When messages need to be processed in order they were sent and one at a time, assuming messages are logically grouped, Message Sessions is the feature Service Bus provides to accomplish the job. The receiver can still scale out and handle multiple sessions concurrently but within any given session only one message will be handled at a time.

Unfortunately, NServiceBus does not support sessions. Sagas soul allow you to accomplish the job but would really clutter the solution because you’d have to store all the incoming messages in the saga’s data (state) and rely on timeouts to execute those. Which, in its own way is not that bad if you have a small number of messages. But if the number of messages is large or their payloads are large, saga becomes a pain point rather than a solution.

If you’d like to have message sessions support in the Service Bus transport, you could upvote the feature request here.

Upvotes: 1

Related Questions