Update transactions.md

Author: belek

code_reading/sql/transactions.md

@@ -52,16 +52,17 @@ COMMIT;
 
  ## Ожидаемые ответы
 1. Возможна проблема “Lost Update” (потерянное обновление)
-   Клиент A уменьшает stock = 5 - 3 = 2, но клиент B видит старое значение stock = 5 и выполняет stock = 5 - 4 = 1.
-	В итоге вместо 2 единиц на складе остается -1 (ошибка)!
+  - Клиент A уменьшает stock = 5 - 3 = 2, но клиент B видит старое значение stock = 5 и выполняет stock = 5 - 4 = 1.
+  - В итоге вместо 2 единиц на складе остается -1 (ошибка)!
 2. В зависимости от уровня изоляции возможны аномалии:
-	READ UNCOMMITTED / READ COMMITTED – клиент B видит “устаревшие” данные, что приводит к ошибке.
-	REPEATABLE READ – клиент B не сможет увидеть обновленный stock клиента A, но проблема не решается полностью.
-	SERIALIZABLE – запросы будут выполняться по очереди, исключая проблему.
-3. Как избежать проблемы:
-	Использовать SELECT ... FOR UPDATE
-	Применять уровень изоляции SERIALIZABLE или REPEATABLE READ
-	Оптимистичные блокировки (проверка stock перед UPDATE)
-4. Лучший уровень изоляции:
-	Если конкуренция высокая → SELECT ... FOR UPDATE + REPEATABLE READ
-	Если важна строгость → SERIALIZABLE (но возможны блокировки)
+  - READ UNCOMMITTED / READ COMMITTED – клиент B видит “устаревшие” данные, что приводит к ошибке.
+  - REPEATABLE READ – клиент B не сможет увидеть обновленный stock клиента A, но проблема не решается полностью.
+  - SERIALIZABLE – запросы будут выполняться по очереди, исключая проблему.
+4. Как избежать проблемы:
+  - Использовать SELECT ... FOR UPDATE
+  - Применять уровень изоляции SERIALIZABLE или REPEATABLE READ
+  - Оптимистичные блокировки (проверка stock перед UPDATE)
+5. Лучший уровень изоляции:
+  - Если конкуренция высокая → SELECT ... FOR UPDATE + REPEATABLE READ
+  - Если важна строгость → SERIALIZABLE (но возможны блокировки)
+