Table of contents

Given problem

Suppose that we have a segment of code:

How do we understand about the Student entity in Hibernate internally?

To be aware of the entity in Hibernate framework, we need to know more about the entity’s state.

Diving into some concepts in Hibernate framework

Before jumping directly into the lifecycle of the entity’s state in Hibernate, we need to be aware of some concepts’s definition.

Introduction to the Hibernate entity’s lifecycle

At this time, we will continue to discuss about the lifecycle of an entity or about the entity’s states.

Below is an image that describe the relationship between an entity’s state.

Entitymanager hibernate что это

  1. An entity object is instantiated by using new operator, that will be called as a transient object.

    The Persistence Context doesn’t managed it. And of course, this transient object doesn’t associated with

    From the transient state to persistent state, there are some methods that supports:

        // Hibernate 5.4

    If the persist() method is called on the detached object, IllegalArgumentException will be thrown.

  2. A persistent object is an object that associates with a database record. From that, the Persistence Context will manage it, and cache that object state, easily be aware of its modification.

    To retrieve the persistent object from a database, some methods will supports:

    Some methods to convert the persistent object to detached object.

         
     // from EntityManager interface
       

       

      

     // from EntityManager interface

  3. После закрытия транзакции контекст персистентности не существует. Тогда приложение по-прежнему будет иметь ссылку на объект в этом постоянном контексте. Таким образом, этот объект считается отдельным объектом.

    Ниже приведены некоторые способы преобразования постоянного объекта в отдельный объект.

    • Когда транзакция (в постоянном контексте области транзакции) фиксируется, объекты, управляемые постоянным контекстом, становятся отсоединенными.
    • Если контекст персистентности, управляемый приложением, закрыт, все управляемые объекты становятся отсоединенными.
    • Использование методов detach(), evict(),clear() и close().
    • Будет вызвано действие отката.
    • В контексте расширенного персистентности, когда bean-компонент с состоянием удаляется, все управляемые объекты становятся отсоединенными.

    Некоторые методы преобразования отсоединенного объекта в постоянный объект:

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

    4. Когда метод delete() или Remove() вызывается для постоянного объекта, этот объект будет преобразован в отсоединенный объект.

    Когда объект удаляется, контекст сохранения удаляет объект из базы данных. Это означает, что нам не следует использовать какие-либо ссылки на удаленный объект в приложении, потому что если какие-то изменения произойдут в этих ссылках, это не отразится на базе данных.

    Если метод удаления() вызывается для отсоединенного объекта, будет выброшено исключение IllegalArgumentException. В противном случае метод удаления() вызывается для постоянного объекта, который находится в двунаправленной связи (с использованием cascade = REMOVE или cascade = ALL) с другим постоянным объектом, после чего для этого постоянного объекта будет вызвана операция удаления. Если метод Remove() вызывается для удаленного объекта, ничего не происходит.

    
 

   // из интерфейса EntityManager

Понимание контекста персистентности для каждого типа EntityManager

  1.

    PersistenceContextType
    перечисление имеет два значения:

    • РАСШИРЕННЫЙ
      — расширенный контекст персистентности

    • СДЕЛКА
      — контекст персистентности в области транзакции.

      По умолчанию значение PersistenceContextType. ТРАНЗАКЦИЯ
      используется.

    Ниже приведена некоторая информация о типе контекста персистентности в EntityManager, управляемом контейнером.

    • Контекст персистентности на уровне транзакции

      Мы можем прочитать о контексте персистентности в области транзакций в разделе Погружение в некоторые концепции Hibernate framework
      .

    • Расширенный контекст персистентности

      Мы можем прочитать о расширенном контексте персистентности в разделе Погружение в некоторые концепции Hibernate framework
      .

      Контекст сохранения создается после вызова EntityManagerFactory.createEntityManager()
      метод. Когда контекст персистентности освобождается путем вызова EntityManager.close()
      метода, объекты в этом контексте персистентности будут находиться в отключенном состоянии.

  2. При использовании EntitManager, управляемого приложением, мы вызываем createEntityManager()
    метод для создания нового EntityManager
    экземпляр, то он будет использовать только Расширенный контекст персистентности
    соответствующий этому EntityManager.

    После вызова EntityManagerFactory.createEntityManager() создается контекст персистентности
    метод. Когда контекст персистентности освобождается путем вызова EntityManager.close()
    метода, объекты в этом контексте персистентности будут находиться в отключенном состоянии.

Синхронизировать постоянный контекст с базой данных

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

  1. после фиксации транзакции.

  2. после вызова методаlush() в этом сеансе.

    Методlush() обновляет базу данных измененными копиями объектов.

    Refresh() обновляет объектную модель последней копией записей, считывая их из базы данных.

    Теперь продолжим работу с режимом смыва. Этот режим очистки может повлиять на производительность при запросе.

    Consider about the FlushMode enum:

           
     // The Session is flushed before every query
     

     // The Session is sometimes flushed before every query execution in order to ensure that queries never return stale state
     

     // The Session is flushed when EntityManager.commit() is called
     

     // The Session is only ever flushed when Session.flush() is explictly called by the application

Wrapping up

  • With the container-managed EntityManager, the persistence context is shared across the multiple Spring Beans or JavaEE’s application components. Otherwise, it’s not right for the application-managed EntityManager.