I see. The main session feature is the ability to limit the number of such sequences of activities that can run in parallel.
The session uses the following design and you can try to implement it yourself:
- Each process creates a separate worker with fixed parallelism (for example 1). Let’s call its task queue “process-lock”.
- Each process listens on a host specific task queue. For example, “host1”.
- To start the sequence of activities invoke “lock-process” activity at “process-lock” task queue.
- This activity starts executing at one of the free processes. While this activity is executing the process is considered locked by the caller.
- The lock activity is expected to run until it is canceled or an “unlock” activity is executed at the host specific task queue.
- When started the “lock” activity sends a “lock granted” signal to the workflow that invoked it. The signal argument contains the name of the host specific task queue to use.
- The workflow upon receiving the signal starts dispatching activities to the host specific task queue as long as needed.
- When the whole sequence of activities is completed the “unlock” activity is dispatched. This activity notifies the “lock-process” activity to complete.
- Once “lock-process” activity is completed the host is considered free and can pick up the next “lock-process” activity from another workflow.
Consider specifying ScheduleToStart timeout for the lock activity to limit how long a workflow is willing to wait for the lock.