Как настроить Hibernate для немедленного применения всех сохранений, обновлений и удалений?

Question

Как настроить Hibernate для применения всех сохранений, обновлений и удалений на сервере базы данных сразу после того, как сеанс выполняет каждую операцию? По умолчанию Hibernate ставит в очередь все операции сохранения, обновления и удаления и передает их на сервер базы данных только после операции flush(), фиксации транзакции или закрытия сеанса, в котором эти операции выполняются.

Одним из преимуществ немедленной очистки операций записи в базу данных является то, что программа может перехватывать и обрабатывать любые исключения базы данных (например, ConstraintViolationException ) в блоке кода, в котором они происходят. В случае поздней или автоматической очистки эти исключения могут возникать спустя долгое время после соответствующей операции Hibernate, вызвавшей операцию SQL.

Обновление:

В соответствии с документацией Hibernate API для интерфейса Сеанс выгода от перехвата и обработки исключения базы данных до завершения сеанса может быть вообще бесполезна: «Если сеанс выдает исключение, транзакция необходимо откатить, а сеанс отбросить. Внутреннее состояние сеанса может не соответствовать базе данных после возникновения исключения. "

Возможно, тогда преимущество «немедленной» операции записи сеанса Hibernate блоком try-catch заключается в том, чтобы перехватывать и регистрировать исключение, как только оно происходит. Есть ли у немедленной очистки этих операций какие-либо другие преимущества?

Answer 1

Как настроить Hibernate на применение всех сохранений, обновлений и удалений к серверу базы данных сразу после того, как сеанс выполняет каждую операцию?

Насколько мне известно, Hibernate не предлагаетлюбое средство для этого.Однако, похоже, что Spring делает, и вы можете иметь некоторые операции доступа к данным FLUSH_EAGER, повернув их HibernateTemplate соответственно HibernateInterceptor вэтот режим сброса ( источник ).

Но я настоятельно рекомендую внимательно прочитать javadoc (я вернусь к этому).

По умолчанию Hibernate ставит в очередь все сохранения, обновления,и удаляет операции и отправляет их на сервер базы данных только после операции flush (), фиксации транзакции или закрытия сеанса, в котором эти операции выполняются.

Закрытие сеанса не сбрасывается.

Одним из преимуществ немедленной очистки операций записи в базу данных является то, что программа может перехватывать и обрабатывать любые исключения базы данных (например, ConstraintViolationException) в блоке кода, в котором они происходят.При поздней или автоматической очистке эти исключения могут возникать спустя долгое время после соответствующей операции Hibernate, которая вызвала операцию SQL

Во-первых, СУБД зависят от того, возвращается ли нарушение ограничения на вставку (или обновление)или при последующей фиксации (это известно как немедленные или отложенные ограничения ).Таким образом, нет никакой гарантии, и ваш администратор базы данных может даже не захотеть немедленных ограничений (хотя это должно быть поведение по умолчанию).

Во-вторых, лично я вижу больше недостатков при немедленном промывании, чем преимущества, как объяснялось черным по белому в javadoc FLUSH_EAGER:

Стремительные промывочные выводыдля немедленной синхронизации с базой данных, даже если в транзакции.Это приводит к тому, что несоответствия немедленно обнаруживаются и выдают соответствующее исключение, и код доступа JDBC, который участвует в той же транзакции, увидит изменения, так как база данных уже знает о них.Но недостатками являются:

• дополнительные обходы связи с базой данных вместо одного пакета при фиксации транзакции;
• тот факт, что фактический откат базы данныхнеобходимо, если транзакция Hibernate откатывается (из-за уже отправленных операторов SQL).

И, поверьте мне, увеличение количества обращений к базе данных и потеря пакетных операторов могут привести к значительному снижению производительности .

Также имейте в виду, что как только вы получите исключение, вы ничего не сможете сделать, кроме как выбросить сессию.

Подводя итог, я очень рад, что Hibernate ставит в очередьразличные действия, и я бы, конечно, не использовал этот EAGER_FLUSH flushMode в качестве общего параметра (но, возможно, только для определенных операций, которые действительно требуют энергичного, если таковые имеются).

Answer 2

Посмотрите на autocommit, хотя это не рекомендуется.Если ваша работа включает более одного обновления или вставки оператора SQL, вы автоматически выполняете часть работы, а затем оператор не выполняется, у вас есть потенциально трудная задача отменить первую часть действия.Когда операция «Отмена» завершается неудачей, становится действительно весело.

В любом случае, вот ссылка, которая показывает, как это сделать .