Блог

Я установил FlushModeType для ФИКСАЦИИ, но сразу после вызова em.persist() ВСТАВКА выполняется в базу данных. Я ожидаю, что Hibernate будет записывать изменения в базу данных только в конце транзакции, но, похоже, это работает по-другому.

Небольшой код для иллюстрации проблемы:

 @Entity
@Table(name="tbl1")
@Inheritance(strategy=InheritanceType.JOINED)
public class TopLevelEntity {}

@Entity
@Table(name="tbl2")
public class MyEntity extends TopLevelEntity { 
  AnotherEntity anotherEntity;      
  //getters and setters
}

@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
public class AnotherEntity { }

public void someTransaction() {
  em.setFlushMode(FlushModeType.COMMIT);

  MyEntity e = new MyEntity();

  em.persist(e);

  e.setProp1(someVal1);
  e.setProp2(someVal2);

}
  

Здесь я ожидаю, что фактическая ВСТАВКА будет выполнена в конце метода, сразу после вызова setProp2() .
Но Hibernate выполняет вставку сразу после вызова em.persist() .

Может кто-нибудь объяснить мне это поведение?

Редактировать:
Я даже пытался использовать FlushMode.РУКОВОДСТВО для сеанса гибернации, но оно все равно выполняет ВСТАВКУ после em.persist . Итак, нет ли способа вручную контролировать, когда выполняется сброс?

Правка2:
Вот проблема, с которой я столкнулся. У меня есть объект A , который имеет-объект B . Объект B еще не существует во время вызова em.persist(a) , и у меня есть «ПРОВЕРКА ОГРАНИЧЕНИЙ (B НЕ РАВНО NULL) в базе данных». Единственное решение, которое я нашел, — использовать отложенное ограничение в Oracle. Однако это решение зависит от поставщика и на самом деле меня не удовлетворяет.

Каскадное
редактирование 3: кажется хорошим решением, но в нашем проекте нам не разрешено его использовать. Нам рекомендуется вручную управлять всеми вставками и обновлениями.

Фиксация в режиме FlushMode не гарантирует, что фиксация произойдет при фиксации транзакции. Это скорее подсказка для поставщика (разработчика спецификаций, например, Hibernate здесь), но он может делать это, когда захочет. Если вы хотите сохранить / обновить компонент, у которого есть новая зависимость, которая еще не существует в базе данных. используйте каскад для операций сохранения / слияния, чтобы также сохранить его. ЕСЛИ вы объявили поле / зависимость как не-nullable, то для JPA нормально не разрешать вам сохранять объект с этим полем / зависимостью null, поскольку он применяет ограничения, которые вы на него накладываете. То, что вы хотите сделать, — это в значительной степени хак / обходной путь вокруг спецификаций JPA. вы либо делаете это поле / зависимость обнуляемыми, если на самом деле оно иногда может быть нулевым, либо вы убедитесь, что оно никогда не равно нулю (и каскадируется, если это новое значение) при сохранении родительского элемента.

Поскольку режим фиксации не гарантирует, что сброс происходит только во время фиксации. Раздел 3.2.4 в спецификации:

Если FlushModeType .Указана ФИКСАЦИЯ, очистка будет происходить при фиксации транзакции; поставщику сохранения разрешено, но не обязательно, выполнять очистку в другое время.

Из-за спящего режима firstlevelcache