Database concurrency control mechanism

Background and characteristics of the problem:

When we use a multiuser database, we often encounter data update failure, deletion, and so on, if there are multiple users and access to a database at the same time when their transactions use the same data can occur concurrency problems.

Concurrency issues include:

1. Lose or overwrite the update. (Phantom Reading)

2. Unconfirmed dependencies (dirty reads).

3. Inconsistent analysis (non repetitive reading).

Detailed Description:

1. Missing updates

A loss update problem occurs when two or more transactions select the same row and then update the row based on the value originally selected. Every transaction has no knowledge of the existence of other transactions. The final update overrides updates made by other transactions, which results in data loss.

For example, two editors made electronic copies of the same document. Each editor changes its copy independently, and then saves the changed copy, overwriting the original document. The editor who finally saved its change copy overwrites the changes made by the first editor. This problem can be avoided if the second editor is able to make changes after the first editor finishes.

2. Unconfirmed dependencies (dirty reads)

An unconfirmed dependency problem occurs when the second transaction selects rows that are being updated by another transaction. The data being read by the second transaction has not been confirmed and may be changed by the transaction that updated the row.

For example, an editor is changing an electronic document. During the change process, another editor copies the document (which contains all the changes made so far) and sends it to the intended user. After that, the first editor decided that the current changes were wrong, and then deleted the edits and saved the document. The document that is distributed to the user contains edits that no longer exist, and those edits should be considered never existed. This problem can be avoided if no one is able to read the changed document until the first editor determines the final change.

3. Inconsistent analysis (non-repetitive reading)

An inconsistent analysis problem occurs when the second transaction accesses the same row multiple times and each time a different data is read. Inconsistent analysis is similar to unconfirmed dependencies because other transactions are also changing the data that the second transaction is reading. In an inconsistent analysis, however, the data read by the second transaction is committed by a transaction that has changed. Also, inconsistent analysis involves reading the same row multiple times (two or more), and each information is changed by another transaction, and the row is not read repeatedly.

For example, an editor reads the same document two times, but between two reads, the author rewrites the document. When the editor reads the document for the second time, the document has changed. The original read cannot be duplicated. You can avoid this problem if the editor can read the document only after the author has finished writing it all.

4. Phantom Reading

A phantom read problem occurs when an INSERT or delete operation is performed on a row that belongs to the range of rows being read by a transaction. The row range for the first read of the transaction shows that one row has ceased to exist in the second or subsequent reads because the row was deleted by another transaction. Similarly, because of the insert operation of another transaction, the second or subsequent read of the transaction shows that a row does not exist in the original read.

For example, an editor changes the document submitted by the author, but when the production department merges its changes to the master copy of the document, it discovers that the author has added the unedited new material to the document. This problem can be avoided if no one is able to add new material to the document until the editor and production department finish processing the original document.

As you can see from above, resolving concurrency mainly uses locks and transactions.

Lock: Locks a record or table in order to add a status representation bit to the current action object so that other users have a judgment when they get edit permission.

Transactions: To ensure the integrity of a set of operations. (either all succeed or all fail)

I do this when dealing with concurrency problems generally:

1. Open the business.

2. Apply for write permission, which means to lock the object (table or record).

3. If it fails, end the transaction and try again.

4. If successful, that is, to lock the object successfully, prevent other users to open in the same way.

5. Edit the operation.

6. Write the results of the edits.

7. If the write succeeds, commit the transaction and complete the operation.

8. If the write fails, the transaction is rolled back and the commit is canceled.

9. (7.8) The two-step operation has freed the locked object and reverted to the state before the operation.