Bulk‑запросы и устаревшие сущности

1. «Bulk обновил, а объект не в курсе»: проблема

Представьте, что вы админ мини‑магазина: нажали кнопку «Деактивировать все товары категории», база данных честно всё обновила, а ваш код внезапно печатает в логах, что товар всё ещё ACTIVE. Начинается лёгкая паника, поиски «где же транзакция» и подозрения в адрес Hibernate (и, возможно, соседей по комнате).

Важный момент: «враньё» обычно проявляется не как ошибка на уровне SQL. SQL‑запрос выполняется нормально. Проблема проявляется в Java‑коде, который продолжает держать ссылку на объект, прочитанный до bulk‑операции, и по инерции считает его актуальным. Это может сломать if‑ветки, логи, формирование ответа наружу, и даже следующую бизнес‑операцию, которая опирается на статус товара.

Давайте посмотрим на минимальный пример — пока без тонкостей про транзакции, только логика в лоб:

import com.example.shopdatajpa.catalog.entity.Product;
import com.example.shopdatajpa.catalog.entity.ProductStatus;

// 1) Загружаем сущность: в рамках текущего persistence context она станет managed
Product product = productRepository.findById(10L).orElseThrow();
System.out.println(product.getStatus()); // ACTIVE

// 2) Выполняем bulk update: меняются строки в БД, но НЕ поля уже загруженного объекта
productRepository.updateStatusById(10L, ProductStatus.INACTIVE);

// 3) Читаем поле из того же Java-объекта: он не обязан «сам обновиться»
System.out.println(product.getStatus()); // ACTIVE (в этом объекте всё ещё старое значение)

Этот код очень хорошо «чувствуется» новичком: «Я же обновил статус — почему в объекте старое?» И вот здесь важно поймать правильную мысль: bulk‑операция меняет строки в БД, но не обязана обновлять уже существующие Java‑объекты. Они не «подписаны на новости из PostgreSQL».

2. Persistence context и first‑level cache

Чтобы понять, почему объект остаётся старым, нужно буквально на пару минут «подсмотреть за кулисы» JPA. Без deep‑dive и без желания переписать Hibernate руками — это опасная мечта, как «я сейчас сделаю свой Spring». Нам достаточно одной ментальной модели: у EntityManager есть persistence context, и он же — first‑level cache.

Когда вы делаете findById(), Hibernate не просто читает строку из таблицы и отдаёт объект. Он ещё и запоминает соответствие «(тип сущности, id) → конкретный Java‑объект». Это нужно по двум причинам. Во‑первых, так обеспечивается «идентичность объекта» внутри работы: если вы дважды читаете один и тот же Product по одному id, вы получаете тот же самый объект, а не две копии. Во‑вторых, это экономит чтения из базы: повторные обращения могут обслуживаться из памяти.

Hibernate прямо описывает это так: как только сущность становится managed, объект попадает во внутренний кэш текущего persistence context. То есть persistence context — это как «рабочая память» ORM: на время выполнения работы он держит ваши сущности под рукой.

Теперь вспомним знакомые состояния сущности: transient, managed, detached, removed. Когда объект managed, он «под контролем» persistence context. Когда detached, он живёт своей жизнью, и Hibernate больше не считает его «живой частью текущей работы».

И вот здесь ключ: bulk‑операции работают напрямую с базой, а не с объектами в этой «рабочей памяти». Поэтому память и база могут разойтись.

3. Bulk‑запрос и рассинхронизация

Теперь соберём картинку в причинно‑следственную цепочку. Bulk update/delete — это запрос вида «обнови/удали все строки, подходящие под условие». Он не подразумевает, что Hibernate сначала загрузит все эти строки как объекты, аккуратно пройдётся циклом и вызовет сеттеры. Он отправляет запрос на уровень базы данных и получает ответ в стиле «затронуто N строк».

Spring Data JPA в официальной документации даже специально предупреждает: после выполнения modifying‑query EntityManager может содержать устаревшие сущности, и поэтому он не очищается автоматически. Почему не очищается автоматически? Потому что очистка, по сути EntityManager.clear(), выбрасывает из контекста все сущности, а это может «уронить» изменения, которые пока существуют только в памяти и ещё не синхронизированы с базой.

И вот мы приходим к «парадоксу новичка»:

1. База данных уже обновилась.
2. Ваш объект в переменной product всё ещё старый.
3. Если persistence context ещё жив (например, в рамках одной общей операции), то даже повторный findById(10) может вернуть тот же самый объект, а не свежую копию.

Это не магия и не ошибка. Это просто два разных мира: мир SQL‑строк и мир Java‑объектов. ORM старается их синхронизировать, но bulk‑операции — это осознанный «короткий путь», где синхронизация не бесплатная.

Чтобы лучше это «увидеть глазами», вот схема того, что происходит:

flowchart TD
    A["findById(10)"] --> B["Product{id=10, status=ACTIVE} в persistence context"]
    B --> C["bulk update status=INACTIVE where id=10"]
    C --> D["БД: status = INACTIVE"]
    C --> E["В памяти: объект всё ещё status = ACTIVE"]
    E --> F["Дальше код читает product.getStatus() и верит ему"]

Самое обидное в этой проблеме то, что она часто не «падает» исключением. Она тихая. Она просто делает неправильные решения в коде.

4. clearAutomatically: очистка контекста

Вот тут на сцену выходит наш сегодняшний герой: @Modifying(clearAutomatically = true). У @Modifying есть атрибут, который буквально описан как «очистить persistence context после выполнения modifying query».

Важная осторожная формулировка: clearAutomatically не «обновляет поля вашего объекта». Он делает другое: он очищает persistence context, то есть «забывает» все managed‑сущности, которые были там закэшированы. Это похоже на ситуацию: «мы сделали массовое изменение данных — теперь давайте договоримся, что всё, что было загружено в память, может быть устаревшим, и не будем этому доверять».

Что это даёт на практике? После очищения:

— уже прочитанные сущности становятся detached (по сути: ORM перестаёт считать их актуальными в рамках текущего контекста);
— следующий findById() (или любой другой запрос) будет вынужден реально читать данные заново, потому что «в памяти» больше нет cached‑версии.

А теперь очень тонкий момент, который обязательно нужно проговорить: если у вас есть переменная product, то после clear() (автоматического или ручного) она никуда не исчезает. Это всё тот же объект в Java‑куче. Он по‑прежнему ACTIVE в поле status. Просто Hibernate уже не будет считать его «истиной» и не будет подсовывать его как результат новых запросов. Поэтому правильная реакция после bulk‑операции звучит так: «Если мне нужна актуальная сущность — я перечитываю её заново».

И ещё раз: почему этот флажок не включён по умолчанию? Spring Data JPA прямо говорит: если автоматически очистить EntityManager, можно выкинуть изменения, которые ещё «живут» только в памяти и не отправлены в базу. Потому clearAutomatically — это не «ставим везде, чтобы было безопасно». Это инструмент, который вы включаете осознанно и точечно.

5. Демо stale‑состояния в shop-data-jpa

Сейчас мы аккуратно встроим проблему в наш сквозной проект shop-data-jpa, чтобы она перестала быть «абстрактной болью из интернета». Сценарий максимально жизненный: у нас есть товары (Product) и статус (ProductStatus). Админ хочет массово деактивировать товары, например, по категории или по дате создания.

Начнём с репозитория. Сделаем два метода: один «обычный bulk update» и второй — «bulk update + auto clear». Так проще увидеть разницу.

import com.example.shopdatajpa.catalog.entity.Product;
import com.example.shopdatajpa.catalog.entity.ProductStatus;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Modifying;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;

public interface ProductRepository extends JpaRepository<Product, Long> {

    // bulk update: Hibernate отправит UPDATE напрямую в БД (без загрузки сущности в память)
    // результат — число затронутых строк
    @Modifying
    @Query("update Product p set p.status = :status where p.id = :id")
    int updateStatusById(@Param("id") Long id, @Param("status") ProductStatus status);
}

А в тот же интерфейс можно добавить вариант с авто‑очисткой:

import org.springframework.data.jpa.repository.Modifying;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;

// В тот же ProductRepository добавляем второй учебный метод
@Modifying(clearAutomatically = true)
@Query("update Product p set p.status = :status where p.id = :id")
int updateStatusByIdAndClear(@Param("id") Long id, @Param("status") ProductStatus status);

Да, в реальном коде вы редко держите оба метода рядом — это учебный контраст. И здесь снова работает простое правило: modifying‑query выполняется в транзакции, иначе запись в БД не начнётся.

Теперь сервисный сценарий‑демонстрация. Я намеренно делаю его transaction‑bound: так видно, что findById() и bulk update живут в одном persistence context. И да, он слегка «странный» — он не про бизнес‑логику, а про диагностику.

import com.example.shopdatajpa.catalog.entity.Product;
import com.example.shopdatajpa.catalog.entity.ProductStatus;
import com.example.shopdatajpa.catalog.repository.ProductRepository;
import org.springframework.transaction.annotation.Transactional;

public class ProductAdminDebugService {

    private final ProductRepository productRepository;

    public ProductAdminDebugService(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    @Transactional
    public void demoStaleObject(Long id) {
        // 1) Загружаем сущность в рамках текущего persistence context
        Product p1 = productRepository.findById(id).orElseThrow();
        System.out.println("Before = " + p1.getStatus()); // Before = ACTIVE

        // 2) Bulk update изменяет БД, но НЕ меняет поля объекта p1 в памяти
        productRepository.updateStatusById(id, ProductStatus.INACTIVE);

        // 3) В этой переменной всё ещё лежит старое значение — отсюда и «магия»
        System.out.println("After  = " + p1.getStatus()); // After  = ACTIVE (stale)
    }
}

Здесь происходит важная психологическая ловушка: человек видит updateStatusById(...), а потом видит p1.getStatus() и думает, что update «не сработал». Но update сработал — просто p1 никто не обновлял. Это обычный Java‑объект.

Теперь добавим проверку «а что в базе на самом деле?». Самый простой способ — перечитать сущность заново, и именно это, кстати, часто является самым безопасным решением для новичка:

// Перечитываем — и получаем состояние, которое реально лежит в БД
Product fresh = productRepository.findById(id).orElseThrow();
System.out.println("Fresh  = " + fresh.getStatus()); // Fresh  = INACTIVE

А теперь покажем, зачем может понадобиться clearAutomatically. Эффект auto‑clear особенно заметен внутри одной общей transactional service operation, где и bulk update, и повторное чтение живут в одном persistence context.

// Предположим, что это всё происходит внутри одной transactional service operation.
Product p1 = productRepository.findById(id).orElseThrow();

// bulk update + автоматический clear persistence context
productRepository.updateStatusByIdAndClear(id, ProductStatus.INACTIVE);

// p2 загрузится заново из БД, потому что контекст уже очищен
Product p2 = productRepository.findById(id).orElseThrow();
System.out.println(p2.getStatus()); // INACTIVE

Ключевое: p1 всё ещё старый объект. Но p2 — уже свежий, потому что после modifying‑query контекст был очищен, и Hibernate не смог «схитрить» кэшем.

6. Стратегии после bulk‑операций

С bulk‑операциями нужно договориться с собой об одном: они почти никогда не про «получить обновлённые объекты». Они про «быстро поменять данные». Поэтому самый здоровый стиль — такой, в котором после bulk update вы не продолжаете жить, опираясь на ранее прочитанные сущности, как будто ничего не случилось.

Если формализовать, у вас есть три «человечески понятных» стратегии. Первая — вообще не держать сущности, а работать от критерия и от результата changedRows. Вторая — после bulk‑операции перечитывать то, что нужно, и не пытаться экономить на одном лишнем запросе там, где важнее корректность. Третья — включать clearAutomatically, когда вы понимаете, что в текущем контексте уже мог накопиться кэш managed‑сущностей и вы рискуете увидеть устаревшее.

Для ощущения разницы удобно посмотреть на маленькую таблицу — не как на догму, а как на шпаргалку для мозга:

Теперь про то, когда clearAutomatically лучше не ставить «на автомате». Если в вашем сценарии до bulk‑операции вы уже сделали какие-то изменения в других сущностях и ещё не синхронизировали их с БД, очистка контекста может выкинуть эти изменения из управляемого состояния. Это ровно та причина, по которой Spring Data JPA не очищает EntityManager автоматически для каждого modifying‑query.

По‑простому: вы можете случайно потерять часть работы, если bulk‑операция выполняется «посередине» большой операции, где уже были изменения объектов. Поэтому хороший junior‑friendly стиль для bulk‑методов — держать их максимально «чистыми» и изолированными по смыслу. Чем меньше вокруг bulk‑операции «живых» сущностей, тем меньше риск stale‑эффектов и тем меньше потребность в магических флажках. И да, звучит скучно. Но скучный код обычно ломается реже — это тот редкий случай, когда скука полезна.

7. Типичные ошибки при bulk‑операциях

Ошибка №1: ожидать, что bulk‑запрос обновит уже существующий Java‑объект.
После update строки в базе изменились, но не поля в вашем объекте. Переменная в Java — это не «умная ссылка на строку таблицы», а обычная ссылка на объект в памяти. Если вам нужно актуальное состояние, его нужно получить заново.

Ошибка №2: строить бизнес‑логику на основе «старого» объекта сразу после bulk‑операции.
Самое неприятное здесь то, что код часто не падает. Он просто идёт в неправильную ветку if, печатает неверный лог или формирует неверный ответ. Если bulk‑операция была частью сценария, пересмотрите место, где вы берёте «истину» для следующего шага.

Ошибка №3: ставить clearAutomatically = true как «оберег от всех бед» на каждый modifying‑метод.
Очистка persistence context — сильное действие. Оно полезно, когда вы действительно хотите «сбросить память» ORM после массового изменения. Но оно может быть вредным, если вы до bulk‑операции успели наделать изменений в управляемых сущностях и рассчитывали, что ORM их донесёт до базы.

Ошибка №4: пытаться после bulk‑операции продолжать использовать ранее загруженный список сущностей как «обновлённый».
Это частный случай первой ошибки, только более дорогой: вы не просто держите один Product, вы держите List<Product>, и теперь у вас в памяти целая коллекция объектов с состоянием «до bulk». Если этот список дальше уходит в расчёты, сортировки, фильтры или формирование ответа — вы сами себе устраиваете день сурка.

Ошибка №5: не замечать, что проблема находится не в базе, а в persistence context / памяти приложения.
Новичок часто проверяет: «в базе статус уже INACTIVE». Значит, «Hibernate сломан». Нет, Hibernate как раз работает предсказуемо: он не будет телепатически обновлять вам объекты после bulk‑запроса. Нужно научиться видеть два слоя: изменения данных в БД и актуальность объектов в памяти.