Для чего нужен readOnly в транзакции?

Концепция read-only (только для чтения) транзакции является важным инструментом управления параллелизмом и производительностью в системах баз данных. Когда транзакция помечена как read-only, разработчик явно сообщает СУБД о своих намерениях: данные будут запрашиваться, но не изменяться. Это позволяет системе применить специфические оптимизации, которые невозможны или небезопасны для транзакций, изменяющих состояние базы данных.

Как это работает и где применяется

На уровне реализации СУБД может предпринять следующие шаги для read-only транзакций:

• Отказ от блокировок на чтение: Для обеспечения изоляции (например, уровня REPEATABLE READ) СУБД часто устанавливает блокировки на прочитанные строки, чтобы предотвратить их изменение другими транзакциями до завершения текущей. В read-only транзакции такие блокировки могут не требоваться, особенно если используется механизм управления версиями строк (MVCC), что снижает накладные расходы и риск взаимоблокировок (deadlocks).
• Использование снимков данных: СУБД может зафиксировать согласованный снимок данных на момент начала транзакции и использовать его для всех последующих операций SELECT внутри неё, гарантируя повторяемость чтения без блокировок.
• Перенаправление на реплику для чтения: В реплицированных архитектурах (master-slave) фреймворк или драйвер базы данных может автоматически перенаправить read-only транзакцию на одну из реплик, разгружая мастер-узел для операций записи.

Типичные сценарии применения:

• Генерация отчётов и дашбордов, требующих сложных агрегаций по большим объёмам данных.
• Выполнение аналитических запросов в OLAP-системах.
• Операции чтения в веб-приложениях, такие как отображение списков товаров, статей или профилей пользователей.

Практический пример

Рассмотрим пример на Java с использованием Spring Framework и аннотации @Transactional:

import org.springframework.transaction.annotation.Transactional;
import org.springframework.stereotype.Service;

@Service
public class ReportService {

    @Transactional(readOnly = true) // Ключевая настройка
    public BigDecimal calculateTotalRevenue(LocalDate startDate, LocalDate endDate) {
        // Сложный запрос только на чтение
        String jpql = "SELECT SUM(o.totalAmount) FROM Order o " +
                      "WHERE o.createdDate BETWEEN :start AND :end";
        // Выполнение запроса...
        // return result;
    }

    @Transactional // По умолчанию readOnly = false (транзакция для записи)
    public void updateOrderStatus(Long orderId, String status) {
        // Операция, которая изменяет данные
        Order order = orderRepository.findById(orderId).orElseThrow();
        order.setStatus(status);
        orderRepository.save(order);
    }
}

В этом коде метод calculateTotalRevenue явно объявлен как read-only транзакция. Spring (и стоящий за ним драйвер/JPA-провайдер) передаст этот hint в СУБД. Метод updateOrderStatus является транзакцией по умолчанию, подразумевающей запись.

Итог: Использование флага readOnly — это простая, но эффективная практика оптимизации. Её стоит применять во всех транзакциях, которые заведомо не изменяют данные. Это снижает нагрузку на базу данных, уменьшает вероятность конфликтов и может повысить отзывчивость приложения, особенно в сценариях с высокой конкурентной читающей нагрузкой.