Overscoped tx и chatty repository

1. Проблема: транзакция «на всякий случай»

Если вы когда‑нибудь видели метод на 80 строк с @Transactional, который «вроде делает полезное», а потом ещё чуть‑чуть — формирует отчёт, сортирует, форматирует, логирует, проверяет какие‑то условия, то вы уже держали в руках зачаток anti-pattern. Он особенно коварный: код работает, тесты зелёные, прод не горит. Но SQL‑поведение становится непредсказуемым, а цена одного use case растёт из‑за мелочей.

После entity leakage это следующая типовая потеря контроля. Даже если сама entity выглядит невинно, длинная транзакция и серия мелких repository‑вызовов быстро превращают use case в источник случайного SQL. Giant graphs, неожиданные flush’и и лишние select’ы очень любят именно такую почву.

Давайте договоримся об одном неприятном факте: Hibernate — это не «просто библиотека сохранения». Это runtime‑система со своими фазами (managed state, dirty checking, flush), и она честно подчиняется вашим границам. Поэтому когда вы растягиваете транзакцию или вызываете репозиторий по одному entity за раз, вы фактически проектируете SQL‑нагрузку — просто делаете это случайно, без дизайна.

Чтобы было проще держать в голове, нарисуем мини‑картинку «как обычно ломают жизнь»:

flowchart TD
  A["Service @Transactional"] --> B[findById в цикле]
  B --> C[mutate]
  C --> D[format/report/logging]
  D --> E["ещё один select 'для проверки'"]
  E --> F[commit]

С точки зрения бизнес‑логики это выглядит как «один метод делает работу». С точки зрения Hibernate это выглядит как «длинный unit of work + куча мелких round trips + больше шансов на неожиданный flush и надувание persistence context».

2. Транзакция и границы unit of work

Транзакцию в Spring/JPA очень удобно воспринимать как «скобочки вокруг кода». Но в Hibernate‑реальности транзакция почти всегда означает ещё и границу жизни persistence context. Это важнее, чем кажется: внутри транзакции объекты становятся managed, Hibernate копит snapshots, отслеживает изменения, а к концу делает flush/commit. Чем шире граница, тем больше объектов вы держите в памяти и тем больше мест, где может возникнуть неожиданная SQL‑активность.

Практическое определение, которое хорошо работает на code review: транзакция должна покрывать ровно тот кусок работы, который обязан быть атомарным. То есть то, что действительно должно либо полностью примениться, либо полностью откатиться. Всё, что не обязано быть атомарным (форматирование текста, подготовка отчёта, подсчёт метрик для логов, конвертация в DTO «для ответа»), очень часто лучше вынести за границу транзакции, потому что оно не выигрывает от наличия persistence context, а риски увеличивает.

Чтобы не звучало как «религия», сравним две модели на одной схеме:

flowchart TD
  subgraph Bad["Overscoped transaction (плохо)"]
    A1["@Transactional"] --> A2["Load + Mutate"] --> A3["Format/report"] --> A4["External call / extra read"] --> A5["Commit"]
  end

flowchart TD
  subgraph Good["Smaller unit of work (здоровее)"]
    B1["Non-tx orchestration"] --> B2["@Transactional: Load + Mutate"] --> B3["Commit"]
    B3 --> B4["Format/report outside tx"]
  end

Мы не говорим «в транзакции нельзя ничего делать кроме save». Мы говорим: транзакция — это дорогая конструкция. Если вы используете её как «контейнер для всего подряд», вы платите за неё в самых неожиданных местах: памятью, блокировками, лишними flush‑триггерами, и — что особенно неприятно — потерей предсказуемости.

3. Overscoped transaction на практике

Слово overscoped звучит как диагноз из больницы архитектуры: «у вас транзакция расширена, примите два рефакторинга до еды». На практике всё проще: транзакция становится overscoped, когда внутрь попадает работа, которая не относится к атомарному изменению данных. Очень часто это происходит из лучших побуждений: «пусть всё будет в одном месте», «так проще», «так точно не будет LazyInitializationException». И да, иногда это даже правда… но цена обычно неприятнее, чем кажется.

Давайте перечислим (в виде связного текста, без чек‑листов) типичные «лишние жители транзакции». Часто туда попадает формирование строки отчёта (StringBuilder), потому что «ну а что такого, это же быстро». Потом туда попадает сортировка и группировка результатов, потому что «всё равно данные уже есть». Потом внезапно туда попадает логирование entity или вычисление items.size(), и это превращается в пачку дополнительных SELECT (особенно если у вас где‑то рядом ещё гуляет entity leakage). Ещё более дорогой вариант — внешние вызовы: HTTP, отправка писем, запись файла, обращения к другим сервисам. Даже если вы не изучаете сейчас distributed systems, вы уже должны чувствовать дискомфорт: транзакция базы данных и внешний вызов живут в разных мирах, а rollback не умеет «откатывать отправленное письмо».

В Hibernate‑контексте overscoped транзакция почти всегда означает три технических эффекта. Во‑первых, persistence context раздувается, потому что вы загрузили больше сущностей и держите их managed дольше. Во‑вторых, dirty checking становится дороже, потому что Hibernate должен сравнивать больше snapshots при flush. В‑третьих, вы создаёте больше точек, где может случиться flush раньше ожидаемого (например, «изменили данные, а потом сделали JPQL‑запрос» — Hibernate обязан синхронизировать контекст, чтобы запрос видел корректную картину).

Вот маленькая табличка, которая помогает объяснять новичкам «что вообще не так», не сваливаясь в лозунги:

Важно: здесь нет запрета «никогда так не делайте». Это список мест, где нужно поднять внутреннюю тревогу и задать себе вопрос «а действительно это должно быть атомарно вместе с изменением данных?».

4. Кейс: закрываем заказы и пишем отчёт

Сейчас будет пример, который выглядит почти невинно, особенно если вы только начали бэкенд‑путь. Мы хотим закрыть несколько заказов и вернуть пользователю текстовый отчёт (хотя бы для админки или лабораторного сценария). Наивный код кажется логичным: открыл транзакцию, прошёлся по id, поменял статус, набрал строки отчёта, вернул результат. В реальности — мы смешали атомарную часть (изменение статуса) и неатомарную (подготовка текста).

Наивная версия:

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

@Service
class OrderClosingService {

    @Transactional
    public String closeOrders(java.util.List<Long> ids) {
        // Транзакция уже открыта, хотя ниже нет ни мутаций БД, ни причин держать persistence context (в примере).
        var report = new StringBuilder();

        // В реальном коде это обычно обрастает findById/setStatus/доступом к lazy-связям — и начинает генерировать SQL.
        for (Long id : ids) report.append(id).append('\n'); // "отчёт"

        // Возвращаем presentation-результат из транзакции: само по себе не ошибка, но часто признак overscope.
        return report.toString();
    }
}

Проблема обычно начинается именно так: транзакция уже открыта, а внутри пошла работа, которая не требует ни managed‑сущностей, ни атомарности. Дальше этот метод почти всегда обрастает findById(), order.setStatus(...), случайным чтением order.getItems().size() и превращается в полноценный SQL‑генератор.

Чуть более «реалистичный» (и уже опасный) вариант:

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

@Service
class OrderClosingService {

    private final OrderRepository orderRepository;

    OrderClosingService(OrderRepository orderRepository) {
        this.orderRepository = orderRepository;
    }

    @Transactional
    public String closeOrders(java.util.List<Long> ids) {
        // Внутри одной транзакции смешаны: чтение/мутация + сбор отчёта (presentation-часть).
        var report = new StringBuilder();

        for (Long id : ids) {
            // Потенциально: один SELECT на каждую итерацию.
            var order = orderRepository.findById(id).orElseThrow();

            // Мутация managed-сущности: Hibernate запомнит изменения и применит их при flush/commit.
            order.setStatus(OrderStatus.CLOSED);

            // Любое обращение к полям/связям может случайно вызвать дополнительные SELECT (особенно при lazy).
            report.append(order.getOrderNumber()).append('\n');
        }

        // Чем «толще» отчёт, тем дольше живёт транзакция и persistence context.
        return report.toString();
    }
}

Проблема не в StringBuilder как в классе (бедный StringBuilder, он вообще-то нормальный парень). Проблема в том, что транзакция стала «мешком для всего», а значит:

Транзакция живёт дольше, чем нужно для изменения статусов. Вы держите persistence context и потенциальные блокировки, пока формируете строку. И если завтра отчёт станет чуть сложнее (с сортировкой, фильтрами, вычислением сумм), вы увеличите время транзакции просто «по дороге».

Сервис начал делать две разные ответственности: атомарное изменение данных и подготовку представления. Это не только про архитектурную красоту: это про то, что если отчёт упадёт из-за NullPointerException на форматировании, вы откатите транзакцию (что, может, и правильно), но место падения будет далеко от сути операции. В отладке это превращается в «почему не закрылся заказ? — потому что отчёт не собрался». И мозг тихо плачет.

Что с этим делать, не залезая в «великий рефакторинг всего проекта»? Первый шаг здесь банален: оставить в транзакции только закрытие заказов, а наружу вернуть минимальные данные для отчёта — например, номера заказов. Тогда String.join(), сортировка и прочая presentation‑логика живут уже после commit и не держат persistence context открытым.

Для этого места важен именно разрез ответственности, а не количество сервисов или красота диаграммы. Mutation должна происходить внутри unit of work. Форматирование и сбор ответа — снаружи, по простым данным, которые уже не могут случайно дёрнуть lazy‑связи. Как только граница становится такой, сразу проще заметить и вторую половину проблемы: даже короткая транзакция остаётся дорогой, если сервис продолжает ходить в БД по одному findById().

5. Chatty repository: сервис-колл-центр для БД

И вот здесь почти всегда всплывает следующая боль: транзакция уже может быть короче, но сервис всё ещё разговаривает с БД слишком мелкими репликами. Термин chatty repository звучит смешно, но проблема очень реальная: один use case собирается из множества мелких обращений к репозиторию, часто в цикле, иногда вложенными циклами. На уровне «код‑стайл» это выглядит как «всё читаемо: вот я беру заказ, потом беру товар, потом беру остаток». На уровне SQL это выглядит как «поздравляю, вы построили мини‑DDoS на свою же базу, просто в одном потоке».

Важно различать два похожих сценария. Если у вас один сервис вызывает два‑три репозитория один раз каждый, это ещё не болтливость — иногда это нормальная координация агрегатов в unit of work. Болтливость начинается там, где репозиторий зовут много раз по одному и тому же шаблону: findById() на каждый id, saveAndFlush() на каждую сущность, existsBy... на каждую проверку. Hibernate при этом не «угадывает», что вы хотели сделать массово — он честно выполняет то, что вы написали.

Самый типичный пример — чтение списка сущностей по списку id:

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

@Service
class ProductLoadingService {

    private final ProductRepository productRepository;

    ProductLoadingService(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    @Transactional(readOnly = true)
    public java.util.List<Product> loadByIds(java.util.List<Long> ids) {
        // Chatty pattern: один findById -> один SELECT. В цикле это превращается в N запросов.
        var result = new java.util.ArrayList<Product>();

        for (Long id : ids) {
            // Потенциально N round trips вместо одного bulk-чтения.
            result.add(productRepository.findById(id).orElseThrow());
        }

        return result;
    }
}

Формально всё хорошо: транзакция read-only, код понятный, ошибок нет. Но по SQL это почти гарантированно будет «один select на каждый id». Если ids = 100, вы только что попросили 100 запросов вместо одного. Это и есть chatty repository: сервис не выражает intent «дай мне набор», он выражает intent «дай мне по одному, и я сам соберу коллекцию».

Первое и самое простое улучшение, не меняющее архитектуру чтения радикально, — использовать bulk‑вызов findAllById():

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

@Service
class ProductLoadingService {

    private final ProductRepository productRepository;

    ProductLoadingService(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    @Transactional(readOnly = true)
    public java.util.List<Product> loadByIds(java.util.List<Long> ids) {
        // Bulk intent: «дай мне набор по списку id» (обычно превращается в WHERE id IN (...)).
        return productRepository.findAllById(ids);
    }
}

Почему это лучше, даже если вы пока всё ещё возвращаете entity? Потому что вы хотя бы перестали «болтать» с БД по одному. В большинстве реализаций Spring Data JPA это превращается в один запрос с where id in (...) (плюс нюансы с пустым списком и т.п.). Hibernate начинает работать с нормальным набором данных, а не с тысячей маленьких «дай‑дай‑дай». Это ещё не design read‑модели, но это уже честный bulk intent: «дай мне набор», а не «дай по одному, а я потом сделаю вид, что это один сценарий».

Есть и вторая популярная форма chatty repository: когда write‑сценарий собирается из save()/saveAndFlush() на каждой итерации. Здесь уже прямой конфликт с тем, что мы учили раньше: managed‑сущность и так будет сохранена через dirty checking, а flush — это отдельная фаза, и делать её на каждой итерации обычно означает «принудительно отправлять SQL прямо сейчас», ломая batching‑возможности и просто делая дорого.

Например (карикатурно, но жизненно):

for (Long id : ids) {
    // Один SELECT на итерацию + ещё и принудительная запись на каждой итерации.
    PurchaseOrder order = orderRepository.findById(id).orElseThrow();

    // Мутация managed-сущности: сама по себе ок.
    order.setStatus(OrderStatus.CLOSED);

    // Почти всегда подозрительно: вынуждает flush сейчас, ломает batching и раздувает стоимость сценария.
    orderRepository.saveAndFlush(order);
}

Даже если вы забудете всё остальное, запомните одну бытовую метафору: saveAndFlush() в цикле — это как после каждого нарезанного огурца мыть всю кухню и заново раскладывать кастрюли. Технически чисто, но почему вы так себя ненавидите?

6. Комбо: длинная транзакция + цикл findById()

Есть редкие случаи, когда overscoped transaction и chatty repositories существуют отдельно. Но чаще они встречаются как друзья‑товарищи: транзакция растянута, потому что внутри неё происходит много мелких repository‑вызовов и лишней пост‑обработки. И тогда SQL‑поведение начинает определяться не use case, а структурой циклов.

Представьте сценарий «закрыть список заказов и посчитать статистику». Наивный разработчик делает так: в одной транзакции грузит заказы по одному, меняет статус, потом для каждого заказа лезет за items (или за inventory), потом строит текстовый отчёт. В итоге у вас в одном методе смешались «изменить состояние» и «посчитать/показать», и вы сами не заметили, как ваша транзакция превратилась в большой мешок с кучей SQL.

В этот момент особенно полезно помнить две идеи, которые мы уже проходили раньше, но сегодня они «склеиваются» в одно целое. Первая идея: чем больше вы делаете внутри транзакции, тем больше шансов, что Hibernate будет вынужден flush’иться перед очередным запросом, чтобы сохранить корректность чтения. Вторая идея: каждый findById() в цикле — это потенциальный отдельный SELECT. Сложите их, и получите сценарий, где даже «небольшая добавка в отчёт» (например, вывести customer.email) неожиданно превращается в десятки дополнительных запросов.

Чтобы не превращать лекцию в «просто страшилки», вот простая таблица вопросов, которую удобно задавать коду, когда вы видите подозрительный сервисный метод:

Заметьте: это не «чек‑лист запретов». Это способ быстро найти места, где границы unit of work размылись, и вернуть код в состояние, где SQL можно объяснить человеку (а не призывать духов Hibernate).

7. Типичные ошибки при работе с транзакциями и репозиториями

Ошибка №1: держать транзакцию открытой ради форматирования и «красивого ответа».
Часто это выглядит как невинный StringBuilder, потом как map -> collect, потом как «давайте ещё отсортируем». В итоге атомарная часть (изменение состояния) занимает 5 строк, а всё остальное — 50 строк «обвязки», которая случайно начинает трогать lazy‑связи и генерировать SQL. Хорошая привычка — сначала отделять «что меняем» от «как показываем», а транзакцию оставлять там, где меняем.

Ошибка №2: собирать набор данных через findById() в цикле, потому что “так проще читать”.
Это один из самых вредных примеров «простоты для разработчика против цены для системы». Цена выражается не в абстракции, а в конкретных запросах. Если вам нужны 100 сущностей, то 100 findById() почти всегда проигрывают одному bulk‑чтению. Даже если вы пока не готовы к полноценному read‑model split, уже одно findAllById() обычно резко улучшает ситуацию.

Ошибка №3: лечить архитектурные проблемы увеличением транзакции.
Иногда разработчик сталкивается с lazy‑поведением, недогрузкой данных или просто «странным местом, где падает», и делает вывод: «надо просто расширить транзакцию». В итоге транзакция начинает захватывать лишние действия, а проблема не решается, а прячется. Такой “фикс” обычно живёт до первого роста нагрузки, после чего оказывается, что транзакция держит ресурсы слишком долго и создаёт пробку.

Ошибка №4: превращать репозиторий в “API по одному объекту”, а сервис — в ручной ORM.
Сервисный слой иногда начинает выглядеть как «я сам orchestrate’ю базу»: достань это, потом это, потом обнови то, потом проверь это. На уровне Java это похоже на аккуратную пошаговую логику. На уровне SQL это похоже на «много мелких запросов, которые могли быть одним-двумя». Репозиторий и query‑слой существуют не только чтобы спрятать EntityManager, но и чтобы выражать намерение чтения более крупными мазками.

Ошибка №5: механически вызывать save()/saveAndFlush() «для надёжности».
Это особенно частая привычка после поверхностной работы со Spring Data. В JPA‑модели, если сущность managed, изменения и так будут сохранены dirty checking’ом. А saveAndFlush() добавляет вам принудительный flush, который может резко поменять момент SQL‑отправки и стоимость сценария. «Надёжность» здесь чаще всего иллюзорна, а цена — вполне реальна.