update: Transaction isolation levels

README.md

@@ -1638,6 +1638,29 @@ The database recovery module can select one of the two operations after a transa
 
 If there isn't any roll-back or the transaction comes from the _committed state_, then the system is consistent and ready for a new transaction and the old transaction is terminated.
 
+## Transaction Isolation Levels
+
+### Read uncommitted
+
+Transactions are not isolated from each other. If the DBMS supports other transaction isolation levels, it ignores whatever mechanism it uses to implement those levels. So that they do not adversely affect other transactions, transactions running at the Read Uncommitted level are usually read-only.
+
+### Read committed
+
+The transaction waits until rows write-locked by other transactions are unlocked; this prevents it from reading any "dirty" data.
+The transaction holds a read lock (if it only reads the row) or write lock (if it updates or deletes the row) on the current row to prevent other transactions from updating or deleting it. The transaction releases read locks when it moves off the current row. It holds write locks until it is committed or rolled back.
+
+### Repeatable read
+
+The transaction waits until rows write-locked by other transactions are unlocked; this prevents it from reading any "dirty" data.
+The transaction holds read locks on all rows it returns to the application and write locks on all rows it inserts, updates, or deletes. For example, if the transaction includes the SQL statement `SELECT * FROM Orders`, the transaction read-locks rows as the application fetches them. If the transaction includes the SQL statement `DELETE FROM Orders WHERE Status = 'CLOSED'`, the transaction write-locks rows as it deletes them.
+Because other transactions cannot update or delete these rows, the current transaction avoids any nonrepeatable reads. The transaction releases its locks when it is committed or rolled back.
+
+### Serializable
+
+The transaction waits until rows write-locked by other transactions are unlocked; this prevents it from reading any "dirty" data.
+The transaction holds a read lock (if it only reads rows) or write lock (if it can update or delete rows) on the range of rows it affects. For example, if the transaction includes the SQL statement `SELECT * FROM Orders`, the range is the entire Orders table; the transaction read-locks the table and does not allow any new rows to be inserted into it. If the transaction includes the SQL statement `DELETE FROM Orders WHERE Status = 'CLOSED'`, the range is all rows with a Status of "CLOSED"; the transaction write-locks all rows in the Orders table with a Status of "CLOSED" and does not allow any rows to be inserted or updated such that the resulting row has a Status of "CLOSED".
+Because other transactions cannot update or delete the rows in the range, the current transaction avoids any nonrepeatable reads. Because other transactions cannot insert any rows in the range, the current transaction avoids any phantoms. The transaction releases its lock when it is committed or rolled back.
+
 # Distributed Transactions
 
 A distributed transaction is a set of operations on data that is performed across two or more databases. It is typically coordinated across separate nodes connected by a network, but may also span multiple databases on a single server.