Что реально делает @Transactional(readOnly = true)?
- Запрещает ли readOnly запись в базу?
readOnly = true — оптимизация чтения: Hibernate не делает снимков и flush (FlushMode.MANUAL), драйверу передаётся подсказка setReadOnly(true), можно направить на реплику. Это не защита от записи: явный UPDATE может пройти.
- Меньше памяти и CPU на больших выборках
- Маршрутизация на реплику — через AbstractRoutingDataSource по флагу
- PostgreSQL с read-only транзакцией отклонит запись — зависит от СУБД и драйвера
А ещё Ставят на сервисы и методы чтения по умолчанию
Подробно
Главный выигрыш даёт Hibernate: он переводит сессию в режим без отслеживания изменений, что экономит память и время на снимках состояния сущностей — на выборках из тысяч записей разница ощутима. Дополнительно соединение может быть помечено как read-only, и некоторые базы и пулы это учитывают, а маршрутизация на реплики для чтения нередко строится именно по этому флагу. Но воспринимать флаг как ограничение прав нельзя: нативный запрос или JDBC-вызов вполне может выполнить запись, а поведение при этом зависит от драйвера и СУБД. И отдельная тонкость: изменение уровня изоляции здесь ни при чём.
Что хотят услышать
- Что оптимизирует readOnly.
- Что это не гарантия отсутствия записи.
- Маршрутизация на реплики — плюс.
Частые ошибки
- Считать readOnly средством защиты данных от изменения.
- Ставить readOnly на метод, который всё-таки пишет, и ловить плавающее поведение.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗Гарантированно блокирует любые изменения, бросая исключение при попытке записи
- ✓Подсказка: Hibernate пропускает dirty checking и flush, но запись не запрещена
- ✗Переводит транзакцию на уровень изоляции READ UNCOMMITTED
- ✗Отключает транзакцию полностью, выполняя запросы вне неё
Что спросят дальше
- Как readOnly используют для маршрутизации на реплики?
- Почему отключение dirty checking экономит память?
Разбор темы
- @Transactional: propagation, isolation, rollback
Декларативные транзакции через прокси, ловушка self-invocation, уровни распространения, правила отката и readOnly/isolation.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.