When the transaction commit or flush method is executed, the state of the entity is written to the database. On the other hand, unless refresh is invoked explicitly, the state of the entity loaded in the memory is not refreshed.
This subsection describes writing of the entity information to the database and reading of the entity information from the database.
This section describes the transition of entity states in the flush operation or transaction commit. The following table describes the state transition results for each entity A state.
Table 6-11 State transition of entity instances in the flush operation or transaction commit
State of entity A | Result of state transition |
---|---|
new | The flush operation is ignored. |
managed | Entity A is synchronized with the database. |
removed | Entity A is deleted from the database. |
detached | The flush operation is ignored. |
Also, if entity A with the managed state has a relationship to entity B, the persist operation is cascaded according to the conditions described in the following table by extending the flush processing.
Table 6-12 Cascading of the flush processing and persist operation in commit for the related entity B
Specification of the cascade attribute of the relationship to entity B | State of entity B | Results |
---|---|---|
PERSIST or ALL is specified | -- | The persist operation is cascaded to entity B. |
PERSIST or ALL is not specified | new |
|
managed | Entity B is synchronized with the database. | |
removed |
| |
detached |
|
Note that if the flush method is invoked outside the transaction, TransactionRequiredException occurs.
If the refresh method of EntityManager is invoked, the changes performed in the entity until then are destroyed and the state of the entity is overwritten by the database contents. At this time, if the corresponding line does not exist in the database, EntityNotFoundException occurs.
If you invoke the refresh method of EntityManager when the state of entity is not managed, IllegalArgumentException occurs.
The entity is read from the database when the refresh method or find method is executed or when a query is issued. The related entities can also be read at this time. This is called the fetch strategy. Specify the fetch strategy in the fetch attribute of each relationship. Specify one of the following types in the fetch attribute:
If you specify FetchType.EAGER, the related field and entity information is read every time the entity information is read from the database. Therefore, specify FetchType.LAZY to prevent the obtaining of unnecessary relation destination entities.
The following table describes the supported range of the fetch attribute in Cosminexus JPA Provider.
Table 6-13 Supported range of the fetch attribute for each relationship
Relationship annotation | Supported range |
---|---|
@ManyToMany | The default value is FetchType.LAZY. |
@OneToMany | The default value is FetchType.LAZY. |
@OneToOne | The default value is FetchType.EAGER. Note that if LAZY is specified, see (b). |
@ManyToOne | The default value is FetchType.EAGER. Note that if LAZY is specified, see (b). |
@Basic | The fetch attribute is ignored. The default FetchType.EAGER is always applied. |
If you specify LAZY in the fetch strategy for a @OneToOne and @ManyToOne relationship, when the entity class is loaded, the binary code is embedded in the getter method for the field specifying LAZY.
If you invoke the getter method, the relation destination entity is obtained from the database through the processing of the embedded binary code. Because the binary code is embedded in the getter method, the getter method used for accessing the field that forms the target of relation must be set up. Furthermore, @OneToOne or @ManyToOne must be specified in that getter method.