Автор оригинала: Vlad Mihalcea.
В моем предыдущем посте я представил переходы состояний сущностей | Объектно-реляционное отображение парадигму.
Все переходы состояний управляемых сущностей преобразуются в соответствующие инструкции базы данных при сбросе текущего контекста сохранения. Поведение при сбросе в спящий режим не всегда так очевидно, как можно было бы подумать.
Hibernate пытается отложить сброс контекста сохранения до последнего возможного момента. Эта стратегия традиционно известна как транзакционная запись .
Задержка записи больше связана со сбросом в спящий режим, чем с какой-либо логической или физической транзакцией. Во время транзакции сброс может происходить несколько раз.
Сброшенные изменения видны только для текущей транзакции базы данных. До тех пор, пока текущая транзакция не будет зафиксирована, другие одновременные транзакции не будут видеть никаких изменений .
Контекст сохранения, также известный как кэш первого уровня , действует как буфер между текущими переходами состояния сущности и базой данных.
В теории кэширования синхронизация с последующей записью требует , чтобы все изменения происходили в кэше, ответственность которого в конечном итоге заключается в синхронизации с резервным хранилищем.
Уменьшение конфликтов блокировок
Каждая инструкция DML выполняется внутри транзакции базы данных. На основе текущей базы данных уровня изоляции транзакций для текущих выбранных/измененных строк таблицы могут быть получены блокировки (общие или явные).
Сокращение времени удержания блокировки снижает вероятность взаимоблокировки и, согласно теории масштабируемости , увеличивает пропускную способность. Блокировки всегда вводят последовательное выполнение, и в соответствии с законом Amdahl максимальное ускорение обратно пропорционально последовательной части выполняемой в данный момент программы.
Даже на уровне изоляции READ_COMMITTED операторы UPDATE и DELETE получают блокировки, чтобы другие параллельные транзакции не могли изменять соответствующие строки.
Таким образом, отсрочка операторов блокировки (ОБНОВЛЕНИЕ/УДАЛЕНИЕ) может повысить производительность, но мы должны убедиться, что это никак не повлияет на согласованность данных.
Дозирование
Отсрочка синхронизации перехода состояния сущности имеет еще одно важное преимущество. Поскольку все изменения сбрасываются сразу, Hibernate может извлечь выгоду из оптимизации пакетной обработки JDBC .
Пакетирование повышает производительность за счет группировки нескольких операторов DML в одну операцию, что сокращает время обхода базы данных.
Поскольку запросы всегда выполняются к базе данных (если только не поражается кэш запросов второго уровня), нам необходимо убедиться, что все ожидающие изменения синхронизированы до начала выполнения запроса.
Таким образом, как JPA, так и Hibernate определяют стратегию синхронизации промывки перед запросом .
| АВТО | АВТО | Сеанс иногда сбрасывается перед выполнением запроса. |
| СОВЕРШИТЬ | СОВЕРШИТЬ | Сеанс сбрасывается только перед фиксацией транзакции. |
| ВСЕГДА | Сеанс всегда сбрасывается перед выполнением запроса. | |
| ИНСТРУКЦИЯ | Сеанс можно сбросить только вручную. | |
| НИКОГДА | Осуждаемый. Вместо этого используйте РУКОВОДСТВО. Это было первоначальное название, данное ручной очистке, но оно вводило пользователей в заблуждение, заставляя думать, что сеанс никогда не будет сброшен. |
Контекст сохранения определяет режим очистки по умолчанию, который может быть переопределен при создании сеанса гибернации. Запросы также могут использовать стратегию очистки, что отменяет текущий режим очистки контекста сохранения.
| EntityManager | Контекст сохранения | Сессия |
| Запрос типа запроса | Запрос | Критерии запроса |
В моем следующем посте вы узнаете , что Режим гибернации FlushMode.АВТО нарушает согласованность данных для SQL-запросов, и вы увидите, как вы можете преодолеть этот недостаток.