Когда режим очистки равен FlushMode.AUTO, это произойдет в следующие моменты:
- Перед выполнением запроса
- Когда транзакция в Hibernate API фиксируется
- Когда приложение явно вызывает session.flush ()
Цель этого режима - избежать устаревшего состояния. Изменения, внесенные в объекты в памяти, могут конфликтовать с результатами запроса. Насколько я понимаю, Hibernate будет выполнять «грязную проверку», сравнивать исходное и текущее состояние объектов. Если они различаются, и Hibernate думает, что это различие подвергнет вас устаревшим данным, он попытается передать это состояние в базу данных. Это возможно, потому что Hibernate знает, какие таблицы будут «затронуты» запросом и какие таблицы нужно будет обновить для текущего грязного состояния.
Взгляните на эту статью :
Авто-промывка довольно умна, когда нужно промывать, хотя
некоторые ситуации могут быть трудно обнаружить. Чтобы улучшить производительность,
Hibernate не просто всегда сбрасывает все, но смотрит на
таблицы в базе данных, к которой обращается запрос, и данные в памяти
это должно быть сохранено в этих таблицах. Если нет перекрытия, нет данных
будет сохраняться Если совпадение обнаружено, весь сеанс будет
промыть, чтобы обеспечить последовательность.
Вы также можете посмотреть org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush исходный код .
Есть пара недостатков FlushMode.AUTO:
- вы не контролируете, когда Hibernate решит выполнить UPDATE / INSERT / DELETE
- потенциальные проблемы с производительностью, потому что каждая модификация объекта может привести к грязной проверке + выполнению инструкции DML
- вы не используете преимущества пакетной обработки и других оптимизаций, которые может выполнять Hibernate, когда он не пытается избежать «устаревшего» состояния
Из-за этих недостатков я предпочитаю FlushMode.COMMIT, который дает вам больше контроля. В этом режиме Hibernate ожидает, пока вы явно не вызовете Commit или Flush, и синхронизирует только состояние в памяти с базой данных.