[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 168 - Lost design patterns
This is the e-mail that I sent Maciej about my concerns regarding issue 168: process flow receive createInstance="yes" correlations correlation set = "foo" initiate = "yes" receive createInstance="no" correlations correlation set = "foo" initiate = "no" In the old world order the previous would have been illegal since an initial activity appears to need to be a start activity and the second receive is not a start activity. In the new world order is the previous illegal? For example, if an engine knows that it will always execute the initiating activity before anything else then it can always execute the previous. If an engine isn't sure it will complete the initiating activity before executing other activities then it might either reject the process statically or throw a runtime error. There is a similar possible race condition between multi-start activities although one can argue that the elephant in the room (i.e. the dispatcher) will always handle that. There is also a race condition between event handlers and start activities in the new design if the event handler is defined on a scope that contains the initiating activity. In other words, it may prove to be impossible to ever define an event handler on a scope that contains a start activity and be sure what the result would be. As a general design pattern, I would imagine that anytime there is an initial receive/pick (including event handlers) that isn't a start activity then it must depend on a correlation set initialization caused by the initiating activity. If we don't clearly specify that an initiating activity always completes before any other initial activities are executed then we make that design pattern effectively impossible. I don't like the idea of losing the initiating non-start receive activity design pattern and it doesn't seem to me like a big deal to just require that the initiating activity completes before any other activity is executed. I especially like it because it neatly resolves the multi-start race condition and so lets us ignore the elephant. What do you think? Yaron
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]