Workflow transaction model Overview

I. workflow transactions

Most workflow processes are a long-lived process. It is normal to encounter various faults and exceptions during execution. Therefore, a transaction processing mechanism should be introduced. The classic transaction model that only meets the acid attribute requirements cannot effectively support transaction processing in the workflow system. Based on the traditional transaction model, many advanced transaction models are proposed, hoping to apply the Advanced Transaction Model to the distributed workflow management that runs for a long time.
However, the execution structure of many advanced transaction models is very limited. A large amount of research shows that no matter whether the workflow management system applies the traditional transaction model or directly uses the Advanced Transaction Model, it is not feasible. In some existing products, the advanced transaction model is rarely applied. Only a small number of prototype systems apply the Advanced Transaction Model and manage workflows using the features of transactions.

Ii. Transaction Model
As people continue to study the transaction problem, the transaction model now mainly includes the classic transaction model applied in the database system and some advanced transaction models based on it. These models have their own characteristics.

1. Classic transactions
Classic transactions generally refer to the transaction processing methods applied in traditional relational databases. It requires the acid feature of transactions. Practice has proved that, due to different characteristics, the workflow system cannot completely copy the Database Transaction processing method. There are similarities and differences between databases and transaction management in workflows. Both transactions in the database and those in the workflow system are designed to protect data consistency and ensure data reliability when errors and faults occur. But there are also many differences, such as: (1) the classic transaction model is mainly for transactions in the database, and data-centric constitutes its main characteristics. Such semantics cannot be directly applied to a workflow. Because the activities in a workflow may be transactional or non-transactional. The transaction in a workflow is different from the transaction-oriented objects in a database or transaction processing system. In contrast, the transaction in a workflow faces more complex objects. (2) The transaction operations in the database are generally executed for a relatively short time, but the transaction activities in the workflow are usually executed for a long time, involving many objects and complicated control logic. The execution of long activities as separate acid transactions seriously delays the execution of other high-priority short transactions. (3) all-or-nothing is too strict and costly for workflow activities. Workflow transactions need to avoid this problem and provide flexible transaction processing. (4) In the classic transaction model, the recovery unit is a transaction. Each transaction has a predefined semantic set which is consistent with the transaction processing system. The recovery model in the workflow is more complex, the restoration process should not only restore the state of the workflow system, but also ensure that the process can continue to be promoted and be consistent with the entire organizational process.
If we regard the entire workflow process as a classic transaction, there will be a series of problems, such as: (1) a long duration increases the possibility of errors in the execution process. Once an error occurs, a large amount of work previously done will be lost according to atomic requirements. (2) Isolation requires that different transactions cannot exchange messages or control messages. However, for collaborative activities in workflows, it is normal that one or more dependencies exist between different transactions. (3) In addition, the locking concurrency control mechanism greatly reduces the throughput of long transactions, in addition, the real-time data exchange between different users is limited, which makes collaboration lose the foundation. (4) users need to perceive the existence of the other party for the collaboration process, especially for Synchronous collaboration. However, in traditional database applications, users can use the database alone and cannot feel the existence of other users.

2. Advanced transactions
Due to the reasons mentioned above, people began to conduct in-depth research on workflow transaction processing. Generally, it takes a long time to execute a workflow. In many cases, manual intervention is required. For example, the time consumed in the ordering and selling processes is even more unpredictable. Long-living transaction is a transaction that requires a long time to run. If we treat a long transaction as an atomic transaction, the system performance will deteriorate, in addition, the atomicity of long transactions may cause the system to occupy resources for a long time and increase the probability of transaction cancellation and deadlock. To solve these problems, many advanced transaction models are proposed based on classic transactions.

A) nested transactions
It is an important step in the evolution of the transaction model. It extends the traditional flat transaction to a multi-layer structure. when a sub-transaction encounters an error, the parent transaction can choose its own recovery measures, reducing the atomic requirement. however, the results of a sub-transaction are visible only after all its parent transactions are successfully committed, so the isolation is not reduced.

B) sagas
Saga model solution: if a long transaction is divided into a series of small transactions, each of which has its own acid attribute, this long transaction is called an saga transaction. When all the small transactions are committed, the entire saga transaction is committed. If a small transaction is canceled after the saga transaction executes, compensation must be made for the small transaction that has been committed.
Basic Principle of the Saga Model: assume that the saga transaction is ts, And the Ts is divided into a series of small transactions T1, T2, T3... TN, each small transaction corresponds to a compensation transaction C1, C2, C3... CN. The system has two execution routes: T1, T2, and T3 .... After TN, the Ts is submitted. The second is sequential execution of T1, T2, T3... Ti, CI, Ci-1 ,... After C3, C2, and c1 are canceled, ts is canceled.
The Saga Model relaxed the separation requirements for transaction operations and increased the concurrency between transactions.

C) Acta
ACTA is a transaction framework that uses the first-level logic to depict the attributes of a transaction, allowing you to reason the attributes of the transaction model. It provides a series of construction modules, such as history, inter-transaction dependencies, transaction views, conflicting sets, and delegation, allowing you to specify the transaction attributes you need, therefore, the requirements for Atomicity and isolation can be easily met. ACTA does not provide access control, nor does it involve scalability. In addition, it is difficult to define a transaction so that it has certain attributes and ensure that the execution history follows these features, which also limits its application field.

D) flexible transaction model
The flexible transaction model is specifically designed for the application of multi-database environments. The concept of equivalent transaction is introduced in the flexible transaction model. When the main transaction fails, it executes the corresponding equivalent transaction to achieve the same effect; it allows the designer to specify the acceptable state of the transaction, so the atomicity requirement is reduced. In addition, support for compensatory transactions reduces isolation requirements.

E) collaborative activity model
The collaborative activity model provides transaction attributes suitable for collaborative scenarios, which relax the requirements for Atomicity and isolation of traditional transactions. It provides simple access control. Each user operates in its own private space, and data exchange with other users is subject to certain constraints. Users can easily join/exit the system, so the scalability is better. This is one of the transaction models that can be seen covering a wide range of application fields. In the four target application scenarios (collaborative writing, industrial design, software engineering, and workflow) of the model, only the prototype of the collaborative writing application is realized.

F) Two-layer Transaction Model
The dual-layer transaction model has been implemented in the wide project. It regards a process as a global transaction and considers that a global transaction is composed of a series of local transactions, which are atomic transactions that strictly abide by the acid characteristics. A global transaction definition diagram corresponding to this process is provided. The execution of this process instance will generate a global transaction execution diagram. It generates a transaction compensation Diagram Based on the global transaction execution diagram. Meanwhile, a formal description of the transaction compensation mechanism is provided, and a dynamic security point is added to reduce the impact scope of local compensation. In the wide project, there is not only a workflow engine, but also a transaction management engine. This transaction management engine emerged as a CORBA component.
Extracted from water disconnection with a knife