Non-repeatable reading
In computer science, non-repeatable read or non-repeatable read describes a problem that occurs when the same read operation successively delivers different results within a transaction .
example
This transaction could be used on a wiki to generate simple user statistics:
- Start of transaction
- Select all usernames with less than five articles listed (action 1a)
- Print out the list of lazy users
- Select all user data sets with fewer than five articles (Action 1b)
- Give these users a more detailed breakdown (age of account, exact number of items, etc.)
- Transaction end
- Start of transaction
At the same time, the following transaction could be part of the operations that take place when a new item is added:
- Start of transaction
- Insert new article (action 2a)
- Increase the number of articles posted by the posting user (Action 2b)
- Transaction end
- Start of transaction
If a user can now display the statistics while another user enters his fifth new article at the same time, the following sequence can occur. In this case, the hiring user would only be displayed in the list of lazy users, but would be missing in the more detailed breakdown (result of action 1b):
| time | Transaction 1 | Transaction 2 | effect |
|---|---|---|---|
| 1 | Action 1a | Action 2a | User is displayed: The article counter is only 4 |
| 2 | Action 2b | Article counter is increased to 5 | |
| 3 | Action 1b | User is not included: He has posted no more than 5 articles |
Depending on how it is implemented in the software , this is a serious source of error, since the software could, for example, rely on receiving further information for all users read at the beginning and could not deal with missing data for a user.
remedy
Databases usually offer the option of transaction isolation . With isolation through serialization , the above sequence could look like this, for example; the read operation becomes repeatable:
| time | Transaction 1 | Transaction 2 | effect |
|---|---|---|---|
| 1 | Action 1a | Action 2a | User is displayed: The article counter is only 4 |
| 2 | [Action 2b] | User table locked: transaction must wait | |
| 3 | Action 1b | User is output because counter has not yet increased | |
| 4th | Action 2b | Transaction continues, counter is increased |