Одна runtime-модель вместо магии 🚀

1. Между сервисным методом и SQL не пустота

После первой лекции уже видно, куда смотреть: проблема не в том, что Hibernate иногда ведёт себя “странно”, а в том, что мы слишком часто представляем его как тонкую прослойку между репозиторием и базой. На практике там живёт куда более интересная система. Если её не увидеть, все дальнейшие темы курса будут распадаться на частные эффекты.

Возьмём снова очень спокойный сервисный метод. Он почти нарочно выглядит безобидно:

@Service // Spring-компонент: класс будет создан как bean
public class CatalogService {

    private final ProductRepository products; // Репозиторий Spring Data как вход в работу с данными

    public CatalogService(ProductRepository products) {
        this.products = products; // Внедрение зависимости (DI)
    }

    @Transactional(readOnly = true) // Транзакционная граница даже для чтения (важно для контекста)
    public Product load(long id) {
        // findById может вернуть Optional.empty(), поэтому orElseThrow
        return products.findById(id).orElseThrow();
    }
}

Обычно такой код читают так: “репозиторий сходил в базу и принёс Product”. Для обычного CRUD-мышления этого хватает. Но для deep-dive этого мало. Здесь важнее другой вопрос: что именно происходит между вызовом load() и SQL-запросом в PostgreSQL?

Удобно держать в голове такую упрощённую карту:

flowchart TD
    %% Важно: это не «магия», а последовательность уровней/компонентов
    A[Service method] --> B[Spring Data Repository]
    B --> C[EntityManager]
    C --> D[Hibernate Session]
    D --> E[Persistence Context]
    E --> F[Flush / SQL generation]
    F --> G[(PostgreSQL)]

Эта схема нужна не только для красоты. Она превращает ORM из “чего-то под капотом” в набор вполне наблюдаемых уровней. Репозиторий — удобный вход. EntityManager — JPA-уровень управления сущностями и запросами. Session — нативный Hibernate-уровень. Persistence Context — рабочая память текущей операции. Flush — фаза синхронизации. А generated SQL — тот самый след в логах, который можно проверить глазами.

И вот здесь появляется первый момент прозрения: большинство ORM-симптомов — это не россыпь отдельных багов, а проявления одной и той же цепочки работы. Пока вы не видите эту цепочку, Hibernate кажется магией. Как только видите — магия заметно сдувается и остаётся инженерная система со своей логикой.

2. EntityManager и Session: два уровня одного стека

Разработчики часто слышали слова EntityManager и Session, но не всегда ясно понимают, как они соотносятся. Из-за этого возникает ложное ощущение, будто это две конкурирующие модели работы с ORM. На самом деле всё проще: EntityManager — это стандартный JPA-интерфейс, а Session — нативный Hibernate-интерфейс, который стоит под ним. Они не воюют друг с другом. Они описывают один и тот же runtime на двух уровнях абстракции.

Если убрать Spring Data и написать чтение чуть ближе к JPA, получится так:

@Service // Обычный сервис Spring
public class ProductFinder {

    private final EntityManager entityManager; // JPA-вход: управляет сущностями/запросами в рамках контекста

    public ProductFinder(EntityManager entityManager) {
        this.entityManager = entityManager; // DI: сюда Spring подставит прокси/реальный EntityManager
    }

    @Transactional(readOnly = true) // Транзакция нужна, чтобы контекст был «жив» на время метода
    public Product load(long id) {
        // Прямой JPA-вызов: поиск по первичному ключу
        return entityManager.find(Product.class, id);
    }
}

Это уже помогает увидеть важную вещь: репозиторий Spring Data не заменяет JPA — он работает через неё. А ключевой JPA-вход в операции с сущностями и запросами — именно EntityManager. 📎

Если же вам нужно заглянуть на уровень Hibernate напрямую, вы не перескакиваете в другую вселенную. Вы просто распаковываете текущую сессию:

@Service // Сервис-адаптер «между» JPA и Hibernate API
public class HibernateBridge {

    private final EntityManager entityManager; // Всё начинается с EntityManager

    public HibernateBridge(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    public Session currentSession() {
        // unwrap: получаем нативный Hibernate Session из JPA EntityManager
        return entityManager.unwrap(Session.class);
    }
}

Эта строчка хорошо снимает лишнюю мистику со стека. Session — не “ещё одна ORM рядом”. Это тот же рабочий контекст Hibernate, через который JPA в нашем приложении и выполняется. Для всего курса этого понимания пока достаточно: работая через Spring Data, вы не обходите Hibernate — вы просто смотрите на него через более высокий слой.

3. Persistence Context: рабочая память ORM 🧠

Теперь самое важное слово этой лекции — persistence context. Звучит чуть академично, но по смыслу это очень практичная штука. Hibernate не работает как примитивный прокси “вызвал метод — сразу SQL — всё забыли”. Он держит рабочее состояние внутри текущей операции. Это состояние и есть persistence context.

У Spring есть свой ApplicationContext, где он хранит beans. А у Hibernate — свой рабочий контекст, тот самый persistence context, где живут entities. Всё в мире циклично.

Если хочется совсем простой образ, думайте о persistence context как о рабочей памяти ORM. В рамках одной операции Hibernate помнит, какие сущности уже были загружены, какие из них сейчас managed, какие изменения произошли, какие связи уже инициализированы, а какие ещё ленивы, и что вообще нужно будет синхронизировать с базой. Это не теоретическая идея. Это реальная часть runtime-поведения.

Из этого сразу вырастает несколько очень практических следствий. Во-первых, внутри одного контекста Hibernate старается держать identity сущности устойчивой: один и тот же row должен соответствовать одному и тому же managed-объекту. Во-вторых, повторные обращения к уже загруженной сущности обрабатываются иначе, чем первое чтение. В-третьих, изменение объекта в памяти — это уже событие для ORM, даже если вы пока не отправили никакого SQL.

Нам сегодня не нужно полностью распаковывать состояния transient, managed, detached и removed. Это отдельный серьёзный разговор, и он скоро станет центральным. Пока достаточно увидеть сам принцип: между вашим кодом и БД существует живой контекст, а не пустой провод. Если вы не держите это в голове, поведение Hibernate действительно кажется спонтанным. Если держите — многие вещи внезапно становятся объяснимыми.

4. Transaction boundary: где живёт unit of work

persistence context почти всегда стоит видеть вместе с ещё одним понятием — transaction boundary. В типичном Spring-приложении эту границу задаёт @Transactional на сервисном методе. И это не просто “аннотация для базы”. По смыслу это рамка одной целостной операции с данными. Именно внутри этой рамки Hibernate и получает шанс держать свой рабочий контекст и вести себя как ORM, а не как набор случайных вызовов SQL.

Очень важно не сводить транзакцию к формуле “один SQL-запрос”. Обычный use case вполне может включать чтение нескольких сущностей, изменение части графа, выполнение дополнительных проверок и только потом синхронизацию результата с базой. В этом и состоит идея unit of work: вы мыслите не отдельными командами JDBC, а одной согласованной операцией приложения.

Посмотрите на простой пример:

@Service // Сервис, где описана бизнес-операция
public class OrderPlacementService {

    private final ProductRepository products; // Чтение товаров
    private final PurchaseOrderRepository orders; // Сохранение заказа

    public OrderPlacementService(ProductRepository products, PurchaseOrderRepository orders) {
        this.products = products;
        this.orders = orders;
    }

    @Transactional // Вся операция выполняется в одной транзакции (и одном persistence context)
    public void placeOrder(long productId) {
        // 1) Загружаем сущность: она становится managed в текущем контексте
        Product product = products.findById(productId).orElseThrow();

        // 2) Создаём новый объект (пока ещё transient)
        PurchaseOrder order = new PurchaseOrder();
        order.setOrderNumber("ORD-1001"); // Заполняем поля доменной модели

        // 3) Сохраняем: объект становится persistent/managed (в терминах контекста)
        orders.save(order);

        // Здесь важен не синтаксис, а сама идея:
        // одна бизнес-операция живёт внутри одной транзакционной границы.
    }
}

Граница транзакции здесь важнее конкретных строк кода. Именно она отвечает на вопрос, где начинается и заканчивается текущая операция, где вообще существует текущий persistence context и в какой момент Hibernate обязан привести его в согласие с базой. Когда потом вы будете диагностировать lazy loading, merge, bulk side effects или locking, этот вопрос станет базовым. Без него дальше не двинуться.

5. Flush и generated SQL: момент истины

И ещё одна ключевая вещь: Hibernate не обязан отправлять SQL ровно в той строке Java, где вы мысленно “совершили действие”. Это непривычно, если вы долго жили в модели “вызвал update() — SQL ушёл”. У ORM между кодом и БД сначала накапливается состояние, а потом наступает отдельная фаза синхронизации. Эта фаза и называется flush.

Сейчас нам не нужен полный каталог flush-режимов. Важно увидеть принцип: flush — это не бытовое “почти commit”, а отдельный момент, когда Hibernate переводит текущее состояние контекста в реальные SQL-команды. Например:

@Service // Сервисный слой
public class ProductRenamer {

    private final EntityManager entityManager; // Работаем напрямую через JPA

    public ProductRenamer(EntityManager entityManager) {
        this.entityManager = entityManager;
    }

    @Transactional // Нужна транзакция, чтобы изменения отслеживались и могли быть зафлашены
    public void rename(long id, String newName) {
        // Загружаем сущность: дальше Hibernate будет отслеживать изменения (dirty checking)
        Product product = entityManager.find(Product.class, id);
        product.setName(newName); // Меняем поле у managed-объекта (SQL ещё может не уйти)

        // Мы изменили managed-объект в памяти.
        // SQL update появится в момент синхронизации, а не здесь как отдельный ручной вызов.
    }
}

В логах это потом может проявиться так:

-- 1) Сначала чтение: Hibernate загружает строку в persistence context
select p1_0.id,p1_0.name,p1_0.sku from product p1_0 where p1_0.id=?
-- 2) Потом UPDATE: результат flush/dirty checking (момент может быть не в строке setName)
update product set name=? where id=?

И вот тут стоит снова вернуться к фразе из прошлой лекции: SQL — детектор лжи для ORM. Вы можете думать, что “ничего особенного не произошло”. Но если в логах ушёл UPDATE, значит для Hibernate это уже была вполне реальная операция синхронизации. Вы можете думать, что чтение было “одним вызовом репозитория”. Но если в логах видно десять запросов, значит use case для базы данных выглядел совсем иначе. 🔬

Поэтому generated SQL в этом курсе — не декоративное сопровождение. Это источник правды. Мы не будем верить Java-коду на слово там, где можно глазами проверить, что приложение реально отправило в PostgreSQL. Это одна из самых полезных привычек, которую вы унесёте уже с первого дня.

6. Диагностическая линза первого дня

Если после этой лекции у вас и должен остаться один переносимый артефакт, пусть это будет не список терминов, а короткая диагностическая линза. Её можно держать рядом с любым странным ORM-кейсом — от LazyInitializationException до лишнего SELECT. Она не заменяет глубокое понимание, но отлично направляет взгляд.

Эта таблица хороша тем, что сразу делает курс практическим. Вы не просто услышали термины EntityManager, Session, flush и persistence context. У вас появился рабочий способ задавать вопросы к поведению Hibernate. И это уже не мотивационная болтовня, а реальная практическая польза.

7. Типичные ошибки понимания runtime-модели

Ошибка №1: думать, что репозиторий и есть вся работа с БД.
Репозиторий — удобный фасад. Но под ним работает JPA-уровень, а под JPA — конкретный runtime Hibernate. Если этого не видеть, почти любая нетривиальная проблема будет казаться “аномалией”.

Ошибка №2: воспринимать EntityManager и Session как разные миры.
На самом деле это разные уровни одного стека. Путаница здесь обычно мешает не в коде, а в голове: разработчик просто не понимает, где искать фактический источник поведения.

Ошибка №3: считать persistence context абстракцией “для теории”.
Как только вы видите неожиданный UPDATE, повторную загрузку, lazy proxy или identity-поведение, вы уже имеете дело с контекстом. Он реален, даже если не виден напрямую.

Ошибка №4: сводить flush к слову “commit”.
Commit и flush связаны, но это не одно и то же. На уровне первой рабочей модели достаточно запомнить: flush — отдельная фаза синхронизации, и именно она часто объясняет “почему SQL ушёл сейчас”.