Problem background and characteristics:
We often touch the data update failure, delete the loss, if you have multiple users and simultaneously access a database, when their transaction uses the same data while using the same data simultaneously.
Concurrent problems include:
1. Lost or override updates. (Phantom read)
2. Unrecognized correlation (dirty reading).
3. Inconsistent analysis (non-recurrent reading).
A detailed description:
1. Lost updates When two or more transactions choose the same line, then update the row based on the original selected value, the problem will be lost. Every business does not know the existence of other transactions. The last update will rewrite the update made by other transactions, which will result in data loss.
For example, two editors have produced electronic copy of the same document. Each editor can independently change its replica, then save the changes after the changes, so that the original document is overwritten. Finally, the editors who have saved their changes have covered the changes made by the first editor. If the second editor can be changed after the first editor is completed, the problem can be avoided.
2. Unconfirmed correlation (Dirty reading) When the second transaction is selected, an undefined correlation problem occurs when the other transaction is being updated. The data that the second transaction is reading has not been confirmed and may be changed by the transaction of the update this line.
For example, an editor is changing the electronic document. During the changes, another editor copys the document (this copy contains all all changes made so far) and distributes it to the expected user. Since then, the first editor thinks that the changes currently do are erroneous, so that the editing is deleted and the document is saved. The document that distributes to the user contains no longer existing editing, and these editing content should be considered that there is no existence. This problem can be avoided if anyone can't read the changes before the first editor determines that anyone can read the changes.
3. Inconsistent analysis (non-recurrent reading) When the second transaction has accessed multiple rows, inconsistent analysis issues occurred while reading different data each time. Inconsistent analysis is similar to unrecognized correlation, because other transactions are also changing the data being read by the second transaction. However, in inconsistent analysis, the data read by the second transaction is submitted by a transaction that has been changed. Moreover, inconsistent analysis involves multiple (twice or more) reading the same row, and each information is changed by other transaction; thus the line is not read.
For example, an editor reads the same document twice, but between two reads, the author rewrites the document. When the editor reads the document for the second time, the document has changed. Original reading is not repetitive. If you can read the document only after the author is completed, you can avoid this issue.
4. Fantasy reads the insert or delete operation on a row, and the row belongs to the range of a row that is being read, and a phantom read problem occurs. The first line of transactions read is displayed in one of the lines that are not repurchable in the second reading or subsequent reading because the row has been deleted by other transactions. Similarly, due to the insertion operation of other transactions, the second or subsequent read display of the transaction has no existing readings.
For example, an editor changes the author submitted by the author, but when the production department merges its changes to the primary copy of the document, it is found that the author has added the unbounded new material to the document. If anyone can add new materials to the documentation before the editorial and production department completes the new material, it can be avoided. -------------------------------------------------- -------------------------------------------------- ---- From the above, it can be seen that it is mainly used to use locks and transactions. Lock: The lock is added to the recording or table is to indicate bits to the current operation object, so that other users have judged when obtaining editing permissions. A transaction: is to ensure the integrity of a set of operations. (Either all succeed, or all fail) --------------------------------------- -------------------------------------------------- --------------- Generally handled concurrent problems, I do this: 1. Open the transaction. 2. Apply for write permissions, that is, to lock the object (table or record). 3. If it fails, end the transaction and try again. 4. If success, it is successful to the object to prevent other users from being opened in the same way. 5. Make an editing operation. 6. Write the editing result of the procedure. 7. If the write is successful, the transaction is submitted and the operation is completed. 8. If the write failed, roll back the transaction and cancel the submission. 9. (7.8) Two-step operation has released the locked object to restore the status before the operation.
