Hibernate Envers выступает в качестве решения для аудита во время транзакции. В конечном итоге это означает, что все постоянные изменения, которые происходят во время транзакции, проверяются и набор операций рабочего блока кэшируется в памяти. Короче говоря, единственный раз, когда Envers сбрасывает операции в схему аудита, непосредственно перед фиксацией успешной транзакции.
Так как же все это работает с точки зрения гибернации?
Hibernate Envers регистрирует 2 очень важные операции обратного вызова с Hibernate ORM, когда обнаружена транзакция, которая работает на проверяемом объекте, до и после обратного вызова завершения транзакции. Обратный вызов до - это то, что фактически выполняет сброс изменений аудита в таблицы аудита, а после отвечает за очистку любых ресурсов, связанных с транзакцией.
Единственный раз, когда на самом деле происходит обратный вызов до , это когда координатора транзакции в спящем режиме просят зафиксировать транзакцию. Если транзакция была помечена для отката при запросе подтверждения, то обратный вызов до пропускается.
Обратный вызов после всегда происходит независимо от состояния транзакции.
Может показаться, что @Transactional создает границу транзакции, а затем вызывается метод для выполнения своих операций, а когда метод завершается, аннотация вызывает фиксацию транзакции, ведущую к наблюдаемому поведению.
Я вижу несколько вариантов для вас:
- Переопределить поведение транзакции для тестов на только для чтения .
- Разработка тестов для очистки их тестовых данных после проверки тестового варианта использования.
- Разработка тестов для работы, даже если в таблицах имеются существующие тестовые данные.
- Отключить Envers через конфигурацию, если она не требуется в рамках этого интеграционного теста.