...
An asynchronous worker would execute each job by updating all dependencies in a single transaction. A message for each dependency would be sent after the single transaction commits.
Concurrency & Consistency
Just like the current implementation, this option would require the use of locks to maintain consistency when the same hierarchy is change concurrently. However, non-blocking locks could be used instead instead of blocking locks. This would involve the worker attempting to acquire a semaphore lock before executing the job. If the lock is not acquired, the message for the job would be returned to the queue for a future retry in the future. The non-blocking locks are less resource intensive than the blocking locks used in the current implementation.
...
The asynchronous job manager will reject any job status change when a stack is in read-only mode. So if a long running job that is started before entering read-only mode, the job will fail shortly after read-only mode is set. The entire job would need to be run in a single transaction so that failure would trigger the rollback of the transaction.
...