CODEWITHSUNDEEP
azure-durable-functions
Gurtz
Gurtz

Reputation: 303

Determinism with Orchestrator/Sub-orchestrator & Durable Entities

If I have an Orchestrator that calls multiple sub-orchestrators, can I safely use a single Durable Entity to share common data across the primary and sub-orchestrators without violating Durable Function determinism rules? I think this is legit, but want to make sure I'm not missing something. Thoughts? Thanks.

Upvotes: 0

Views: 109

Answers (1)

Bjorne
Bjorne

Reputation: 1484

Yes, durable entities are safe to use across multiple orchestrators with the OrchestrationTrigger binding. With this binding, it will only read the entity one time and then put it in a table to be used on subsequent runs so it is deterministic. It will also guarantee that all operations are processed in order across multiple orchestrators because they operate on queues and only process one operation at a time.

But as with any distributed system operating working on the same data, it is prone to race conditions and async operations. This must be considered when developing.

ex. a counter with a initial value 5

Orch1 -> Get -> returns 5, commited value is now 5
Orch2 -> Get -> returns 5, commited value is now 5
Orch1 -> Set 5 + 1 -> commited value is now 6
Orch2 -> Set 5 + 1 -> commited value is now 6

increment instead or get and increment in one operation

Orch1 -> GetAndIncrement 1 -> returns 5, commited value is now 6
Orch2 -> GetAndIncrement 1 -> returns 6, commited value is now 7

Note: If this entity is also accessed by a normal functions with ReadEntityStateAsync then there exists a situation when this data reads the current committed state and not in sequence. This is because it then reads it from the storage table directly instead of calling it with the queue. ex. value is 5

Orch1 -> GetIncrement 1 -> return 5, commit 6
Func1 -> ReadState -> depending on how close to the last operation it is made there is a possibility of it returning 5 or 6.

Upvotes: 1

Related Questions