Отключить автоматическое обновление Hibernate при сбросе на синонимах только для чтения

У меня есть таблица и две базы данных, которые имеют одну и ту же таблицу, но одна является символической ссылкой другой, и в этой таблице разрешено только чтение.

Я сопоставил таблицу с Java с помощью Hibernate, и я использую Spring, чтобы установить источник данных Entity Manager в качестве одной из двух баз данных на основе некоторых критериев ввода.

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

Как отключить это обновление только для второго источника данных и сохранить его нормальным для первого?

Обновить: Глядя на трассировку стека, кажется, что сброс начинается здесь:

          at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
          at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
          at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027)
          at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365)
          at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:504)
          ... 55 more

Это связано со свойством hibernate.transaction.flush_before_completion? Могу ли я установить значение false для второго источника данных?

Ответы на вопрос(2)

Решение Вопроса

ваши сущности становятся «грязными» в тот момент, когда они загружаются из базы данных, и Hibernate считает, что необходимо сохранить изменения. Это происходит, если ваши методы доступа (методы get и set) имеют не возвращает точно такое же значение или ссылку это было установлено Hibernate.

В нашем коде это произошло со списками, разработчики создали новые экземпляры списков, потому что им не понравился тип, который они получили в установщике.

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

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

является ли это DDL или DML. Если вы не знаете, то я рекомендую вам установить Hibernate.show_sql = истина чтобы запечатлеть оскорбительное высказывание.

Если это DDL, то, скорее всего, Hibernate обновит схему для вас, и вы захотите дополнительно настроить Hibernate.hbm2ddl.auto устанавливается либо "Обновит" или "никт ", в зависимости от того, используете ли вы фактическую базу данных или символическую ссылку (только для чтения), соответственно. Вы можете использовать" Validate "вместо ни одного тоже.

Если это DML, то сначала я бы определил, по какой-то причине ваш код вносит изменения в экземпляр, который все еще подключен к активной сессии Hibernate. Если это так, то последующее чтение может вызвать сброс этих изменений без явного сохранения объекта (Grails?). Если это так, рассмотреть вопрос об исключении случая сброса (или вместо этого использовать транспортные объекты).

Возможно, вы используете какие-либо аспекты или события жизненного цикла Hibernate для проверки объектов? Это также может привести к доступу только для чтения, что приведет к запуску вставки или обновления.

Может оказаться, что вам нужно предоставить альтернативные сопоставления классу-нарушителю, если в игру вступает возможность обновления поля, но код делает все именно так, как вы хотите (это маловероятно; 0). Если вы находитесь в мире аннотаций, это может быть сложно. Если вы работаете с hbm.xml, то обеспечить альтернативное отображение прощ

 Arvind29 июн. 2009 г., 09:10
Это не DDL, он выпускает только DML, я использую только аннотации, а не hbm.xml. Глядя на трассировку стека, кажется, что обновление запускается из-за этого: 375400 в org.hibernate.impl.SessionImpl.managedFlush (SessionImpl.java:365) 375401 в org.hibernate.ejb.AbstractEntityManagerImpl $ 1.beforeCompletion (AbstractEntityMan: 504) 375402 ... еще 55 Это связано с настройкой hibernate.transaction.flush_before_completion?

Ваш ответ на вопрос