9.10.1 Optimistic lock processing

(1) Procedure for checking whether the data is updated

Whether the data is updated is checked by the presence or absence of update of the version column prepared in the database table. If the data in the database is updated, the version number of the version column is updated. As a result, the user understands that the database was updated by another application. The following table describes the states and operations of the version column when the database is updated.

Table 9‒16: States and operations of the version column when the database is updated

State of the version column in the table	Operation
When the value of the version column is not updated	Cosminexus JPA Provider applies the entity information to the database. At this time, the value of the version column in the database is updated.
When the value of the version column is updated	Indicates that the database data is being updated by another application. Therefore, Cosminexus JPA Provider throws OptimisticLockException and marks the transaction for rollback.

In this way, using the state of the version column, you can ensure that another transaction does not update the data during the period from the reading of the entity until the database is updated.

To Page Top

(2) Checking the versions of the persistence fields and relationships

To use the optimistic lock, you check the versions of both persistence fields and relationships of the entities. To check the versions, set the Version field (property) corresponding to the version column for the entity. Set the Version field by using @Version or the <version> tag of the O/R mapping file.

The version of the entity is checked at one of the following timings:

• When the entity state is changed and that change is written to the database

• When the entity state is changed to managed by the merge processing^#

  #

  The version is not only checked during the execution of merge, but also during flush or when the transaction is committed.

When the version of the entity is determined to be old by the version check, OptimisticLockException occurs. The transaction is also marked for rollback.

To Page Top

(3) Checking the versions during the flush operation or transaction conclusion

You can check the version of the entity during the flush operation or transaction conclusion. To check the version, specify the entity in the lock method of EntityManager. By using the lock method of EntityManager, you can add the entity as a target for version check in the transaction and change the update policy of the version column.

Cosminexus JPA Provider supports LockModeType.READ and LockModeType.WRITE as the timing for updating the version column (LockModeType of the lock method). Regardless of the content specified in the update timing for the version column, Cosminexus JPA Provider ensures that the following two events do not occur during transaction conclusion:

• Dirty Read

  Transaction T1 changes a line. Then, before T1 executes commit and rollback, another transaction T2 reads the same line and obtains the changed value. Finally, T2 succeeds in commit.

  Whether T1 executes commit or rollback is no longer important, but whether T1 performs commit or rollback before or after commit by T2 becomes important.

• Un-Repeatable Read

  Transaction T1 reads a line. Then, before T1 executes commit, another transaction T2 changes or deletes that line. Finally, both the transactions succeed in commit.

If you specify LockModeType.WRITE as the LockModeType, the version column is forcefully updated even when there is no change in the entity state. The version column is updated when flush or transaction commit is invoked. Note that if the entity is deleted before the version column is updated, the update of the version column might be omitted.

To Page Top