What anomalies can occur during parallel transactions?

Parallel transaction execution can lead to the following anomalies:

1. Lost Update: One transaction overwrites changes made by another transaction before those changes are committed.

   Time	Transaction 1	Transaction 2
   t1	Reads Balance value (e.g., 100)
   t2		Reads Balance value (e.g., 100)
   t3	Increases Balance by 10 (Balance = 110)
   t4		Increases Balance by 20 (Balance = 120)
   t5	Commits changes (Balance becomes 110)
   t6		Commits changes (Balance becomes 120)

   Result: Despite two increments, the final Balance value is 120, not 130. The increment from Transaction 1 is lost.

2. Dirty Read: One transaction reads uncommitted changes made by another transaction. If the transaction that made the changes rolls back, the read data becomes invalid.

   Time	Transaction 1	Transaction 2
   t1	Starts changing Balance (100 -> 110)
   t2		Reads Balance (receives 110)
   t3	Rolls back change (Balance reverts to 100)
   t4		Uses Balance = 110 in calculations, although the actual value is 100

   Result: Transaction 2 bases its actions on data that ultimately was not committed.

3. Non-Repeatable Read: During a single transaction, repeated reads of the same row yield different values because another transaction has committed changes to that row between reads.

   Time	Transaction 1	Transaction 2
   t1	Reads Balance (receives 100)
   t2		Changes Balance to 110 and commits
   t3	Reads Balance again (receives 110 instead of 100)

   Result: The Balance changes within the same transaction, which can lead to incorrect results.

4. Phantom Read: Similar to non-repeatable read, but involves the addition or removal of rows that affect the results of a query with a predicate.

   Time	Transaction 1	Transaction 2
   t1	Executes SELECT COUNT(*) FROM Orders WHERE Status = 'Pending' (gets 5)
   t2		Adds a new order with status 'Pending' and commits
   t3	Executes SELECT COUNT(*) FROM Orders WHERE Status = 'Pending' again (gets 6)

   Result: Repeated execution of the query results in "phantom" rows that were not present during the first read.

These anomalies are prevented by using different transaction isolation levels.