Какие знаешь проблемы у каждого уровня изоляции?

Проблемы на каждом уровне изоляции транзакций

Уровни изоляции транзакций определяют, как одновременно выполняющиеся транзакции взаимодействуют друг с другом. Каждый уровень предлагает баланс между консистентностью данных и параллелизмом. Рассмотрим проблемы каждого уровня.

1. Уровень READ UNCOMMITTED (Грязное чтение)

Самый низкий уровень изоляции. Транзакция может читать незафиксированные данные других транзакций.

Основные проблемы:

Грязное чтение (Dirty Read)

Транзакция читает данные, которые ещё не были зафиксированы:

// Транзакция A (читает)
Connection connA = getConnection();
connA.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

ResultSet rs = connA.createStatement().executeQuery(
    "SELECT salary FROM employees WHERE id = 1"
);
// Может получить salary = 100000 (ещё не commited)

// Транзакция B (в другом потоке) откатит UPDATE
connB.rollback();
// salary вернулся к 50000

// Результат: Транзакция A прочитала несуществующее значение!

Проблемы:

• Работа с фантомными данными
• Принятие решений на основе несуществующих значений
• Потенциальная потеря данных при откате других транзакций
• Никогда не используется в production

2. Уровень READ COMMITTED (Чтение подтверждённых данных)

Транзакция может читать только зафиксированные данные. Это уровень по умолчанию в большинстве СУБД.

Основные проблемы:

Неповторяемое чтение (Non-repeatable Read)

Данные между двумя чтениями в одной транзакции могут измениться:

Connection conn = getConnection();
conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
conn.setAutoCommit(false);

// Первое чтение
ResultSet rs1 = conn.createStatement().executeQuery(
    "SELECT salary FROM employees WHERE id = 1"
); // salary = 50000

// Другая транзакция обновляет и коммитит
// UPDATE employees SET salary = 100000 WHERE id = 1
// COMMIT

// Второе чтение в той же транзакции
ResultSet rs2 = conn.createStatement().executeQuery(
    "SELECT salary FROM employees WHERE id = 1"
); // salary = 100000 (другое значение!)

conn.commit();

Фантомное чтение (Phantom Read)

Множество строк, возвращённых в одном запросе, может отличаться при повторном запросе:

// Первое чтение
ResultSet rs1 = conn.createStatement().executeQuery(
    "SELECT COUNT(*) FROM employees WHERE department = 'IT'"
); // count = 10

// Другая транзакция вставляет новую строку
// INSERT INTO employees VALUES (..., 'IT', ...)
// COMMIT

// Второе чтение
ResultSet rs2 = conn.createStatement().executeQuery(
    "SELECT COUNT(*) FROM employees WHERE department = 'IT'"
); // count = 11 (появился фантом!)

Проблемы:

• Бизнес-логика может работать с неконсистентными данными
• Сложность в отчётах и аналитике
• Race conditions в многопоточных приложениях
• Требует дополнительной синхронизации на уровне приложения

3. Уровень REPEATABLE READ (Повторяемое чтение)

Транзакция видит согласованный снимок данных на момент начала. Изменения других транзакций не видны. Используется в MySQL по умолчанию.

Основные проблемы:

Фантомное чтение (Phantom Read)

Хотя REPEATABLE READ предотвращает неповторяемое чтение, он НЕ предотвращает фантомное чтение:

Connection conn = getConnection();
conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
conn.setAutoCommit(false);

// Первый SELECT с условием
ResultSet rs1 = conn.createStatement().executeQuery(
    "SELECT * FROM orders WHERE status = 'PENDING' FOR UPDATE"
); // 5 заказов

// Другая транзакция вставляет новый PENDING заказ
// INSERT INTO orders VALUES (..., 'PENDING', ...)
// COMMIT

// Второй SELECT с тем же условием
ResultSet rs2 = conn.createStatement().executeQuery(
    "SELECT * FROM orders WHERE status = 'PENDING'"
); // 6 заказов (новый фантом появился!)

Проблемы с обновлениями

Если одна транзакция прочитала строку и вторая её обновила, первая может не увидеть изменения:

-- Транзакция A
BEGIN;
SELECT * FROM users WHERE id = 1; -- balance = 1000

-- Транзакция B (параллельно)
UPDATE users SET balance = 500 WHERE id = 1;
COMMIT;

-- Транзакция A
UPDATE users SET balance = balance - 100 WHERE id = 1;
-- balance станет 900 (считаёт от 1000, не видя 500!)
COMMIT;

Проблемы:

• Потеря обновлений
• В финальном состоянии данные неконсистентны
• Сложнее тестировать и воспроизвести
• Требует особой осторожности при обновлениях

4. Уровень SERIALIZABLE (Полная изоляция)

Самый высокий уровень. Транзакции выполняются так, как будто они идут одна за другой. Но это имеет огромную цену.

Основные проблемы:

Крайне низкая производительность

Транзакции блокируют друг друга, параллелизм минимален:

// Транзакция A
conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
Connection conn = getConnection();
conn.setAutoCommit(false);

ResultSet rs = conn.createStatement().executeQuery(
    "SELECT * FROM orders WHERE customer_id = 1"
); // Блокирует все строки, попадающие под условие

Thread.sleep(10000); // Долгая операция

// Транзакция B ждёт, ничего не может сделать
// Даже простой SELECT блокируется

conn.commit(); // Только теперь B может продолжить

Deadlock'и

Высокая вероятность deadlock'ов при множественных транзакциях:

// Транзакция A
BEGIN SERIALIZABLE;
UPDATE table1 SET col = 1;
// ждёт блокировки table2

// Транзакция B
BEGIN SERIALIZABLE;
UPDATE table2 SET col = 1;
// ждёт блокировки table1

// DEADLOCK! Обе транзакции ждут друг друга

Неиспользуемость в высоконагруженных системах

На production серверах с тысячами подключений SERIALIZABLE становится узким местом.

Проблемы:

• Невозможно добиться хорошей масштабируемости
• Частые deadlock'и требуют retry логики
• Даже для чтения есть блокировки (очень странно для разработчиков)
• Используется только в специфичных случаях

Сравнительная таблица

Практические рекомендации

Для большинства приложений используй READ COMMITTED:

Connection conn = getConnection();
conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
// Это уровень по умолчанию в PostgreSQL и Oracle

Для критичных операций используй pessimistic locking:

BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE;
-- Никто другой не может изменить эту строку
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

Для конкурирующих обновлений используй optimistic locking:

public class Account {
    private long id;
    private BigDecimal balance;
    @Version
    private long version; // Hiberate автоматически проверит версию
}

// При UPDATE проверится, что version не изменилась
accountRepository.save(account); // Выбросит OptimisticLockException если конфликт

REPEATABLE READ используй только если явно требуется:

// Редко, например для аудита или отчётов
conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);

SERIALIZABLE избегай в production:

// Только для очень специфичных случаев
// В 99% случаев есть лучшее решение
// (locking, pessimistic/optimistic, snapshot isolation)