Business data concurrency mutex Analysis

During enterprise application system development, in the multi-user mode, it is very important to consider how to avoid data exceptions caused by concurrent operations on various business data. The following summarizes some of the scenarios and corresponding solutions that have been encountered, which are incomplete and comprehensive.

Scenario: simultaneously edit the same business data

Problem description:

A opens the edit header of a business data, and B also opens the edit header. A and B successively perform the keep operation.

For example, if no control is made during storage, the data in the later warranty period overwrites the data in the earlier warranty period.

Ø Solution:

After the edit header is opened, save the business data Timestamp and check whether the timestamp is consistent. If the data is inconsistent, the system prompts you to choose whether to save the data.

Advantage: give users the right to choose. Disadvantage: The user may not be able to judge the data, which may cause data exceptions.

Note:

When the Edit page contains the edit and save functions of sub-tables, solution A may cause data exceptions. Unless the sub-table is saved first and then added.

 

Ø Solution B:

After the edit header is opened, save the business data Timestamp and check whether the timestamp is consistent. If the difference is not consistent, the system prompts that the service data cannot be saved.

 

Ø Solution C:

Do not control, only record the retention time and the person who saves the record

 

Scenario: changing the status of business data in the Business Process

Problem description:

A opens a business data for review. before clicking review, B opens the business data modification and maintains it first;

 

A opens a business data for review. before clicking review, B opens business data modification. A clicks review and B clicks save;

(Changes to "Review", "Void", or other special business status fields of business data apply to this scenario)

Ø Solution:

When the viewing page is opened, the record Timestamp and the review timestamp are compared. When saving business data, it is also a timestamp and cannot be saved at the same time.

 

Ø Solution B:

The review action is divided into two steps: "submit for review" and "confirm for review". After the review is submitted, it cannot be modified.

Vulnerability: Before a submits an action on the review page, B opens the modification page, and a confirms the review. Then, B saves the modification, in this case, the review operation may be incorrect in terms of business and data status.

 

Ø Solution C:

When you open the Edit page, record the business status value and compare the value when saving it. If it is different, it cannot be saved.

 

Scenario: business data is deleted while being edited

 

Problem description:

A opens the business data for editing, B deletes the data, and a then saves the data.

Ø Solution:

When saving, check whether the business data exists. Generally, business data is retrieved by ID to determine whether or not the data exists. If so, the data is modified and saved.

If the client does not exist, the customer information is fed back and cannot be saved.

 

Scenario: The business associated data is deleted.

Problem description:

A opens the business data. In this case, a related data in the business data is deleted and the value of the associated data cannot be obtained based on the associated information.

A. Edit the business data and select an associated data. B. Delete the associated data and perform the keep operation.

 

Ø Solution:

Set foreign key fields in the database to avoid data exceptions at the database level. In the program, the customer is prompted by capturing exceptions.

Defect: Depends on the database, which may cause performance problems in some cases (Note 1 );

Note 1: If table A is set as A foreign key Association for multiple tables, and the associated table has A large amount of data, updating the fields in Table A may result in checking and updating other associated tables at the same time, resulting in A significant performance reduction.

Ø Solution B:

The associated data cannot be deleted from the business.

Defects: large amount of code, easy to omit;

 

Methods A and B can complement each other.

 

Scenario: business associated data is modified

Problem description:

In business data, the associated data is changed. For example, the customer name in the contract table is originally A, and the customer table ID is saved in the contract. Then, the name of A in the customer table is changed to B. On the contract page, the customer name is changed to B.

The correct solution for this scenario is heavily dependent on specific business scenarios. For the above example, assume that the only way to modify the customer name is to modify the customer table. The above phenomenon may be normal business performance. If the customer name in the contract cannot be changed at will, the above phenomenon is a data exception.

 

Ø Solution:

When modifying the customer name, check whether the Union is related. If so, you cannot modify the customer name or design another page (Business Channel.

Defect: applicable only when the association is strong. The code is large and the business logic is complex.

 

Ø Solution B:

Record key information such as the customer's name and contact information in the contract. In essence, redundancy is used to prevent key information from being modified. You can also select fields in the synchronized customer information table.

Defect: applicable only when the association is strong. The code is large and the business logic is complex.

 

Ø Solution C:

Not handled. The customer is prompted only during implementation.