Transactions vs Concurrency
Last updated
Last updated
Concurrency issues arise only when multiple transactions operate on the same data item. If transactions work on different data items, concurrency is not a problem. However, when multiple transactions are executed concurrently in an unpredictable manner, several issues can occur. Database transactions primarily involve two major operations: "Read" and "Write." Effectively managing these operations during concurrent transaction execution on the same data item is crucial to maintaining data consistency in the database.
A transaction reads shared data that has been modified by another transaction but that transaction is not yet committed (Uncommitted data is read).
When a user reads a set of records, and then another transaction inserts or deletes rows in the dataset being read. When the user reads the same set of records again, they may find new "phantom" rows that were not present during the initial read.
Before transaction A is over, another transaction B also accesses the same data. Then, due to the modification caused by transaction B, the data read twice from transaction A may be different.
The difference between Phantom read and Non-repeatable readοΌ
The key to non-repeatable reading is to modify: In the same conditions, the data you have read, read it again, and find that the value is different. The key point of the phantom reading is to add or delete: Under the same conditions, the number of records read out for the first time and the second time is different.
