9.4.5 Synchronization with the database

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 section describes writing of the entity information to the database and reading of the entity information from the database.

Organization of this subsection

(1) Writing the entity information to the database
(2) Reading the entity information from the database

(1) Writing the entity information to 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 9‒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 9‒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`	In the `flush` operation `IllegalStateException` occurs and the transaction is marked for rollback. In the commit processing `IllegalStateException` occurs and the transaction commit operation fails.
	`managed`	Entity B is synchronized with the database.
	`removed`	In the flush operation `IllegalStateException` occurs and the transaction is marked for rollback. In the commit processing `IllegalStateException` occurs and the transaction commit operation fails.
	`detached`	When entity A is the owner of the relationship The change in the relationship is synchronized with the database. When entity B is the owner of the relationship An exception occurs. With Cosminexus JPA Provider, the operations in this case are not supported.

Legend:: --: Not applicable

Note that if the flush method is invoked outside the transaction, TransactionRequiredException occurs.

Tip

Persistence relation for relationship and database

A managed entity having a bi-directional relationship is perpetuated on the basis of the reference stored in the owner side of the relationship. The application developer must create an application so that when changes occur, the entity is stored in the owner side and the non-owner side respectively without conflicting with the state of the entity on the memory.
For unidirectional OneToOne and OneToMany, it is the developer's responsibility to guarantee that the relation of the relationships defined in the entity and the relation between the database tables is matching.

To Page Top

(2) Reading the entity information from the database

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.

(a) Timing when the entity information is read from the database

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:

FetchType.EAGER

When the entity information is read from the database, the related field and entity information is read.
FetchType.LAZY

When the field or relation destination is accessed for the first time, the entity is read from the database. This is called Lazy loading.

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 9‒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.

(b) LAZY fetch in @OneToOne and @ManyToOne

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.

Important note: The getter method determines the type of the relation destination entity from the targetEntity type of the relationship. The type of class specified in targetEntity must be castable in the field or property type.

To Page Top