Comment 11 for bug 1524477

Lingxian,

On the other thought your suggestion makes sense to me now for a different reason. We need to make DB transactions as short as possible so that this would be a good optimization because we wouldn't have to have heavy DB querying.

We used to have the calculation model you mentioned before. We moved away from it because architecturally it wasn't convenient to have this "cause_task" param all over the place. And there's a number of situations when there isn't any cause tasks. For example, when we need to resume a workflow from pause.

So my suggestions are the following:
* We need to understand precisely why it doesn't work now so that we don't have hidden surprises in the future
* We need to optimize calculation of next tasks
* Ideally we need to move away from using locks and thereby improve parallelism. For example, by using optimistic concurrency

Anyway, let's not rush and understand first all pros and cons of all solutions.

Thanks