This can happen when a Transaction tries to read the DB row multiple times and gets different results each time e.g. if T1 reads a DB row at 2 different times, and in between these 2 reads, T2 updates the row.
Açıklaması şöyle
If a transaction reads a database row without applying a shared lock on the newly fetched record, then a concurrent transaction might change this row before the first transaction has ended.
Aynı veriyi iki defa okuyup farklı sonuçlar alan bir örnek şöyle
The best example is, a client might order a product based on a stock quantity value that is no longer a positive integer). With the Read-Committed isolation level, it is possible to avoid non-repeatable (fuzzy) reads.
Örnek
Şeklen şöyle
Açıklaması şöyle
1. Alice and Bob start two database transactions.2. Bob’s reads the post record and title column value is Transactions.3. Alice modifies the title of a given post record to the value of ACID.4. Alice commits her database transaction.5. If Bob’s re-reads the post record, he will observe a different version of this table row.
Hiç yorum yok:
Yorum Gönder