Нужно ли коммитить транзакцию только с SELECT запросами?

# Нужно ли коммитить транзакцию с SELECT запросами

Краткий ответ

Технически не обязательно, но это зависит от уровня изоляции транзакции, СУБД и используемых инструментов.

Детальный разбор

Поведение разных СУБД

PostgreSQL

// В PostgreSQL SELECT запросы не требуют COMMIT
// для завершения транзакции

try (Connection conn = dataSource.getConnection()) {
    Statement stmt = conn.createStatement();
    
    // Читаю данные в транзакции
    ResultSet rs = stmt.executeQuery("SELECT * FROM users");
    while (rs.next()) {
        System.out.println(rs.getString("name"));
    }
    
    // COMMIT не требуется для SELECT
    // Транзакция закроется автоматически
} // Автоматический rollback при закрытии

Однако есть нюансы!

Oracle

Орacle ведёт себя иначе:
- Автокоммит по умолчанию ВЫКЛЮЧЕН
- SELECT запросы "видят" uncommitted changes
- Нужно COMMIT или ROLLBACK явно

Проблема: Autocommit режим

// ❌ ОПАСНО - если autocommit=true
Connection conn = dataSource.getConnection();
conn.setAutoCommit(true); // По умолчанию true в Java

ResultSet rs = conn.executeQuery("SELECT ...");

// COMMIT уже произошёл автоматически!
// Даже если SELECT не изменяет данные

// ✓ БЕЗОПАСНЕЕ - явное управление
Connection conn = dataSource.getConnection();
conn.setAutoCommit(false); // Явное управление транзакциями

ResultSet rs = conn.executeQuery("SELECT ...");
// Данные читаются в контексте текущей транзакции

conn.commit(); // или rollback()

Уровни изоляции транзакций

ВЫБОР уровня изоляции важен:

1. READ UNCOMMITTED

conn.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);

// Могу прочитать "грязные" данные (uncommitted changes)
ResultSet rs = conn.executeQuery("SELECT * FROM accounts WHERE balance > 0");

// Другой процесс может откатить свои изменения
// и мои расчёты будут на основе грязных данных

2. READ COMMITTED (рекомендуемый)

conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);

// Читаю только коммитнутые данные
ResultSet rs = conn.executeQuery("SELECT * FROM accounts");

// Безопаснее для SELECT запросов
conn.commit(); // Хорошо явно коммитить

3. REPEATABLE READ

conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);

// Один SELECT должен видеть консистентное состояние
ResultSet rs1 = conn.executeQuery("SELECT balance FROM accounts WHERE id=1");
// ... какой-то код ...
ResultSet rs2 = conn.executeQuery("SELECT balance FROM accounts WHERE id=1");

// rs1 и rs2 вернут ОДИНАКОВОЕ значение
// (даже если другой процесс делал UPDATE)

conn.commit();

4. SERIALIZABLE (самый строгий)

conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);

// Полная изоляция - как будто нет конкурентности
ResultSet rs = conn.executeQuery("SELECT * FROM accounts");

// Медленнее, но гарантирует консистентность
conn.commit();

Практические сценарии

Сценарий 1: Simple read-only query

@Transactional(readOnly = true)
public List<User> getAllUsers() {
    // Spring автоматически управляет транзакцией
    return userRepository.findAll();
    // COMMIT происходит при выходе из метода
}

// В SQL уровне:
BEGIN;
SELECT * FROM users;
COMMIT; // Происходит автоматически

Это правильно! SELECT в транзакции с COMMIT гарантирует:

• Консистентное чтение
• Освобождение ресурсов
• Очень быстрый COMMIT (на SELECT'е)

Сценарий 2: SELECT с последующим UPDATE

@Transactional
public void transferMoney(Long fromId, Long toId, BigDecimal amount) {
    // Читаю в транзакции
    Account from = accountRepository.findById(fromId).orElseThrow();
    Account to = accountRepository.findById(toId).orElseThrow();
    
    // Проверяю баланс (SELECT уже в транзакции)
    if (from.getBalance().compareTo(amount) < 0) {
        throw new InsufficientFundsException();
    }
    
    // Обновляю (INSERT/UPDATE)
    from.setBalance(from.getBalance().subtract(amount));
    to.setBalance(to.getBalance().add(amount));
    
    accountRepository.save(from);
    accountRepository.save(to);
    
    // COMMIT с UPDATE - обязателен!
}

SQL:
BEGIN;
SELECT * FROM accounts WHERE id=1; -- Блокировка (FOR UPDATE)
SELECT * FROM accounts WHERE id=2; -- Блокировка
UPDATE accounts SET balance=... WHERE id=1;
UPDATE accounts SET balance=... WHERE id=2;
COMMIT; -- ОБЯЗАТЕЛЕН для UPDATE

Сценарий 3: Только SELECT

@Transactional(readOnly = true)
public Map<String, Long> getStatistics() {
    long totalUsers = userRepository.count();
    long totalOrders = orderRepository.count();
    // Только SELECT запросы
    
    return Map.of(
        "users", totalUsers,
        "orders", totalOrders
    );
    // COMMIT после этого экономит ресурсы
}

Сценарий 4: SELECT с блокировкой

@Transactional
public Account getAccountForUpdate(Long id) {
    // SELECT FOR UPDATE - нужна транзакция!
    return accountRepository.findByIdForUpdate(id);
}

@Query("SELECT a FROM Account a WHERE a.id = ?1 FOR UPDATE")
Account findByIdForUpdate(Long id);

SQL:
BEGIN;
SELECT * FROM accounts WHERE id=1 FOR UPDATE; -- Экскл. блокировка
-- Другие процессы не могут читать эту строку
UPDATE accounts SET balance=... WHERE id=1;
COMMIT; -- ОБЯЗАТЕЛЕН!

Когда COMMIT важен

1. Освобождение ресурсов

// БЕЗ COMMIT - ресурсы заблокированы
BEGIN;
SELECT * FROM orders FOR UPDATE;
-- Другой процесс ждёт...
-- Ресурсы заняты
-- COMMIT ещё не вызван!

// С COMMIT - ресурсы освобождены
BEGIN;
SELECT * FROM orders FOR UPDATE;
COMMIT; -- Другой процесс может читать

2. Видимость данных

// Транзакция 1
BEGIN;
SELECT * FROM users; -- Видит состояние на момент BEGIN
-- но НЕ видит INSERT из транзакции 2
-- (в зависимости от уровня изоляции)

3. Откат при ошибке

@Transactional
public void complexOperation() {
    userRepository.save(user);
    
    if (someError) {
        throw new Exception(); // ROLLBACK автоматически
    }
    // COMMIT если всё ОК
}

Best Practices

1. Используй @Transactional(readOnly = true)

// ✓ Правильно
@Transactional(readOnly = true)
public List<User> findAll() {
    return userRepository.findAll();
}

// ❌ Неправильно - без транзакции
public List<User> findAll() {
    return userRepository.findAll(); // Неопределённое поведение
}

2. Минимизируй scope транзакции

// ❌ Плохо - транзакция слишком широкая
@Transactional
public void processUsers() {
    List<User> users = userRepository.findAll(); // 1000 пользователей
    
    for (User user : users) {
        // Долгие операции
        expensiveCalculation(user);
        sendEmailToUser(user);
    }
}

// ✓ Хорошо - разделил на части
@Transactional(readOnly = true)
public List<User> getAllUsers() {
    return userRepository.findAll();
}

public void processUsers() {
    List<User> users = getAllUsers();
    for (User user : users) {
        processUserOutsideTransaction(user);
    }
}

3. Будь осторожен с SELECT FOR UPDATE

// ❌ Может привести к deadlock
@Transactional
public void dangerousCode() {
    Account a1 = findForUpdate(1); // LOCK
    Account a2 = findForUpdate(2); // LOCK
    // Если другой процесс: findForUpdate(2) потом findForUpdate(1)
    // → DEADLOCK!
}

// ✓ Правильный порядок
@Transactional
public void safeCode() {
    Account a1 = findForUpdate(1); // LOCK 1
    Account a2 = findForUpdate(2); // LOCK 2
}

Ответ на исходный вопрос

Нужно ли коммитить SELECT?

ДА, рекомендуется:

1. Освобождение ресурсов - блокировки удаляются
2. Консистентность - явное завершение транзакции
3. Предсказуемость - понятное поведение
4. Производительность - БД может оптимизировать

Но:

• В autocommit режиме SELECT коммитится автоматически
• В read-only транзакциях Spring коммитит автоматически
• COMMIT на SELECT очень быстр (практически бесплатен)

Заключение

Да, нужно коммитить даже SELECT-only транзакции, потому что:

• Освобождаются блокировки
• Улучшается читаемость кода
• COMMIT на SELECT очень дешёв
• Гарантируется консистентность данных

Используй @Transactional(readOnly = true) для read-only операций - Spring сделает COMMIT автоматически.