process-flexibility.com

Sunday, 04 August 2013 21:25

Change Support Feature FF7: Change Concurrency Control

PAISs supporting instancespeci c adaptations (cf. Feature F2), should be able to cope with concurrent changes. For example, two users might want to apply di erent ad-hoc changes to a particular process instance at the same time. If this is done in an uncontrolled manner, errors or inconsistencies (e.g., deadlock-causing cycles) can occur (Design Choice F7[1]). Or, the execution of an instance proceeds (i.e., the state of the instance may change) while an ad-hoc change is concurrently applied to it. Here we have to ensure that the state change does not violate state constraints required for the correct application of the ad-hoc change (or at least the ad-hoc change has to be prohibited in such cases). The easiest way to avoid respective con icts is to prohibit concurrent changes in general (Design Choice F7[2]). This can be achieved, for example, by holding exclusive locks on a
process instance when changing its structure or state (e.g., an instance must not proceed while applying an ad-hoc change to it). Although this approach is easy to implement, it is usually too restrictive due to the long-term locks required (e.g., when a change is de ned interactively by a user this might block instance execution for a while). A more exible approach would allow for concurrent changes of the structure or state of a process instance, and further ensure that this does not lead to errors or inconsistencies afterwards (Design Choice F7[3]). Both, pessimistic and optimistic techniques can be applied in this context to control such concurrent instance changes and to ensure their correctness. Pessimistic locking is an approach where the process instance to be modi ed is locked until the change is accomplished. In contrast, optimistic concurrency control does not put a lock on the process instance, but checks for con icts when commiting changes.

Finally, we have to deal with "concurrent" changes at the process type and the process instance level. For example, assume that an instance-speci c change is applied to process instance I , which was originally created from process schema S. Assume further that later process schema S evolves to S 0 due to a change at the process type level. Then, the challenging question is whether the process type change can be propagated to I as well. Although I has undergone an instance-speci c change this should not mean that it must not migrate to the new schema version S' (particularly not if I is long-running). Note that respective considerations only have to be made for systems supporting both changes at the process type and the process instance level (Design Choice F7[4]).

Read 780 times
 

Get the Book!

book cover small