9.7.4 Notes on using the cache functionality

This section describes the notes on using the cache functionality of the entity objects.

Organization of this subsection

(1) Notes on updating or deleting the data in a query
(2) Notes on multiple persistence contexts using a cache
(3) Notes on the cache registration and update timing

(1) Notes on updating or deleting the data in a query

When JPQL and native query are used in the application to update and delete the data, the cache contents are not updated. Execute operations such as the refresh operation to obtain the database contents again.

The cache data is read in the following operations; therefore, the data is not updated in the database:

The data is read into the entity object.

The entity data is registered in the cache as well.
The delete query containing the data read in 1 is executed.

The data is deleted by the execution of the delete query, but the cache is not deleted.
The same data as in 1 is read into the entity object.

Because the data is the same as 1, the data existing in the cache is read.
The data in 3 is flushed.

The applicable line does not exist in the database, so the add or update processing cannot be performed.

To Page Top

(2) Notes on multiple persistence contexts using a cache

By using the cache, you can reduce the database access frequency. However, on the other hand, a time lag occurs in the data due to the cache and the frequency of optimistic lock exception might increase.

A cache exists for each persistence context. Therefore, multiple EntityManagers existing in pairs with the persistence contexts are generated simultaneously, and if the entities with the same primary keys are operated at the same time, even if the data is updated, the user might not be able to reference the updated data in a timely manner. Due to this, the optimistic lock exception occurs easily.

The following points describe the mechanism and action for the occurrence of the optimistic lock exception.

(a) Example of optimistic lock exception

This section describes an example of cache for each persistence context in the environment shown in the following figure.

Figure 9‒19: Environment described in this example

In the figure, the cache and the database are consistent and data A is already stored in the cache.

In persistence context 1, the data is changed from A to B.

At this time, the contents of the cache and the database are identical, so an exception does not occur.

Figure 9‒20: Changes in data in persistence context 1

After the processing of 1 ends, A data is changed in persistence context 2.

The cache data is not changed; so the database data and the cache are inconsistent. Therefore, an exception is thrown due to the optimistic lock.

Figure 9‒21: Changes in data in persistence context 2

In such an environment, if you use the cache, the non-updated cache is left behind and an exception might occur due to the optimistic lock.

(b) Action

When an optimistic lock exception occurs, the relevant objects in the cache are deleted. Therefore, execute the find method or the refresh method to obtain all the related data from the database once again. With this, you can synchronize the cache data and the database.

To Page Top

(3) Notes on the cache registration and update timing

When you use JPQL to obtain the pessimistic lock, the entity object returned when the query is executed is not registered in the cache.
When a native query is used to execute the query that sets the entity as the return value in @SqlResultSetMapping, the entity object of the return value is stored in the cache.
During the refresh operation of an entity, if OptimisticLockException occurs in another thread after the entity object is read and the cache is deleted, the entity object is not registered in the cache even if the refresh processing is executed.

To Page Top