Question on concurrent RecipeInstances

[sebukoleth]

First of all apologies for raising this as an issue, but I was not able to figure this out from the documentation.
Consider this usecase: multiple RecipeInstances are started concurrently for the same Recipe. More than one of these RecipeInstances is at the same InteractionInstance. Does Baker make sure that IngredientInstances go to the right InteractionInstance?
Drawing on the Order example imagine we have two RecipeInstances started for two sets of orders. An InteractionInstance requires ReserveItemsOutcome. InteractionInstances from both the RecipeInstances are waiting. How can we use Baker to make sure that the ReserveItemsOutcome with the right 'orderId' goes to the right InteractionInstance?

[jacum]

Recipe instances are independent and run along each other.
Interaction instances are just stateless functions and could indeed be used by any recipe instance.
Each recipe instance performs its own call to the interaction, and has no knowledge of underlying implementation.
Each call to an interaction is performed independently of any other calls to the same interaction. You can think of an interaction as an HTTP server, which multiple clients can call, simultaneously, each in its own context, each getting its own result. Hope this answers your question.

It is however up to the actual interaction implementation to serialise the calls and guarantee the integrity of the data behind that interaction.
In your example, if you have two orders running concurrently, and you need to reserve same SKU for each order independently, you do need to use some sort of locking/transaction on your stock data, or a queue, to guarantee that you won't reserve the same stock twice for two orders.