Repository navigation
Ordered delivery using Azure Service Bus Transport - #8569
poornimanayar wants to merge 27 commits into
Conversation
| var numberOfItems = orderState?.ItemCount ?? 0; | ||
|
|
||
| var publishOptions = new PublishOptions(); | ||
| publishOptions.SetSessionId(message.OrderId.ToString()); |
There was a problem hiding this comment.
@SzymonPobiega I think a session id like "Sales" is better. The orderid is high cardinality if we want all OrderPlaced event to be handled in the order they come in at the Inventory endpoint. Otherwise the event for each order could be handled in parallel which defeats the purpose of reserving inventory in the order of orders as they come in
There was a problem hiding this comment.
I understand your comment in the context of this sample, but in a real system, I think sessionid=orderid makes a lot of sense because they will have plenty of messages that belong to the same order which is where you want the order. You don't necessarily want order across your sales because that's not really something a retail company would optimize for, so I would still leave it as it.
What we want to convey to users is: use a unique sessionid per context in which you want to maintain ordering.
There was a problem hiding this comment.
I think sessionid=orderid makes a lot of sense because they will have plenty of messages that belong to the same order which is where you want the order.
Yes thats how the Client app works. But when I think about the OrderPlaced event, in the context of the sample I would want it to be processed in the order in which the orders arrive so that inventory is reserved in that order. Having OrderId as session id does not make sense to me in that situation especially given for a given order we have a single OrderPlaced event.
There was a problem hiding this comment.
I have tried to explain that here in the sample.md file https://github.com/Particular/docs.particular.net/pull/8569/changes#diff-b62eab01a996295ab9e4247cf9b07e66b07f330257072540e41ab304e547abe3R38
There was a problem hiding this comment.
What we want to convey to users is: use a unique sessionid per context in which you want to maintain ordering.
If this is what we should convey to users I think we should not use OrderId as the session id in the sample.
There was a problem hiding this comment.
I disagree you'd want to keep order for inventory in a real system except for companies that sell old stock or so and have limited items. Either way, whatever thing we want to show, I think we just need to agree on what that is, clarify it in the sample too. Without context, "sales" does not make sense to me.
SzymonPobiega
changed the title
poornimanayar
changed the title
3 participants
No description provided.