6.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 subsection 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 6-11 State transition of entity instances in the flush operation or transaction commit

State of entity AResult of state transition
newThe flush operation is ignored.
managedEntity A is synchronized with the database.
removedEntity A is deleted from the database.
detachedThe 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 BState of entity BResults
PERSIST or ALL is specified--The persist operation is cascaded to entity B.
PERSIST or ALL is not specifiednew
  • 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.
managedEntity 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.

Hint
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.

(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:

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 annotationSupported range
@ManyToManyThe default value is FetchType.LAZY.
@OneToManyThe default value is FetchType.LAZY.
@OneToOneThe default value is FetchType.EAGER. Note that if LAZY is specified, see (b).
@ManyToOneThe default value is FetchType.EAGER. Note that if LAZY is specified, see (b).
@BasicThe 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.

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.