Jpa,eclipselink Caching mechanism Learning (a) Thinking of tree node search problem

Recently, the project has been developed in a way that uses Jpa+eclipselink, where Eclipselink uses version 2.5.1. Encounter some problems caused by improper use of the cache, starting from this chapter to learn the Eclipselink caching mechanism.

One, tree node search problem appears

The story is this: there is a need for a tree node search in the project, as shown in the prefix matching query node name contains OK node, will return the data structure in. The basic implementation is: 1. Find the OK node first, and then get the parent node based on the node's parent node ID, which is the PERSON2 node, and also find the root of the nodes according to the PERSON2 's parent nodes ID. The class diagram of the node is probably the same, and after each parent node is acquired, it joins the parent node to the Children collection.

(Figure A)

Strange phenomena occur in the operation at the beginning in a particular order.

Step 1. Retrieves the node that contains OK as normal, B shows.

Step 2. Retrieves the node that contains the person name, as shown in the result c.

Step 3. Another time to retrieve the OK node, the results of strange results appear, see Figure D. The ideal result data is not PERSON1, which is obviously a cache-led problem.

(Figure B) (Figure C) (Figure D)

Second, Eclipselink cache architecture

Several of these basic concepts:

1. Session cache, which is the persistence Unit cache, belongs to the system-level cache and all clients share data. There are two main sources of data:
A) When the data is read through the Entitymanager, a copy of the read data is copied to the session Cache;
b) When the Unit of work cache succeeds, the data is synchronized to the session cache;

2. Unit of work cache, which is the persistence Context cache, belongs to the isolated cache and belongs to a single client. Managed by Entitymanager, the persistence context holds a read entity instance. When a commit operation is performed on an entity, the data is synchronized to session Cache after the change. The flush,clear operation does not trigger a synchronous session cache operation.

3. Data query process. Entitymanager to see if the instance exists in the persistence Context cache, based on the instance unique identity, and returns the instance if it exists. If it does not exist, the query persistence the unit cache for the instance, if present, returns the instance directly, if it does not exist, accesses the database for querying, and then saves the data to the persistence Unit cache and Persistence the context cache.

III. Entity Cache Isolation Type (determines whether query data is stored in the shared cache)

1.SHARED
Shared cache, which is also the system default configuration. Enittymanger The returned data is saved as part of the session cache/entitymanagerfactory when the query operation is performed.

2.PROTECTED
to be protected. Enittymanger The returned data does not save the full entity instance in the session cache when the query operation is performed, only the entity state information is saved.

3.ISOLATED
Isolated. Enittymanger the data returned will not be saved in session cache/entitymanagerfactory when the query operation is performed, only in persistence Context Cache.

four . Entity cache type (determines cache validity time)

1.FULL
All instances of the entity's query are cached and can be obtained through the cache at any time through a unique identity. Because the cached data is not purged by the GC, beware of the fact that a large number of entity instance objects can cause out of Memory.

2.WEAK
Caches all entity instances of the cache as a reference to weak reference. When the GC executes, the cache is purged.

3.SOFT
Caches all entity instances of the cache as a reference to soft reference. This portion of the cache is freed when the JVM is low on available memory.

4.soft_weak
This is the system default configuration. Caches all entity instances of this cache in a way that combines soft Reference with Weak Reference. The difference between this cache type and the weak type is that there is a soft reference-based most-frequently-used sub-cache, and the most frequently read entity instances are saved here to avoid GC reclamation of frequently read entity instances. The child buffer size can be adjusted by setting the Size property in @cache.

5.hard_weak
This cache type is similar to Soft_weak, except that the sub-buffers are stored with hard Reference, ensuring that this portion of the cached data is not purged even if the JVM is low on memory.

6.CACHE
The cache uniquely identifies that the map maintains a cache of a specified size, and the object is moved out of the cache policy according to LRU (Least recently used).

7.NONE
No cache is made for the entity.

V. The cause of the search problem
Using SPRING-DATA-JPA, the persistence layer is implemented through the inheritance interface org.springframework.data.jpa.repository.JpaRepository. The implementation class is found to be org.springframework.data.jpa.repository.support.SimpleJpaRepository according to the debug results. Each of these simplejparepository instances has a entitymanager, and the member variables of the Entitymanager type do not change (hashcode the same) during the service after the repository instantiation. It can be considered that the same persistence Context Cache is used. According to the previous analysis of the cache, the node type cache isolation type is shared, the cache type is soft_weak, each time according to the ID of the node query is first from the persistence context cache, the results of the step In 2, the root object was set up in Children,step 3, and then it was obtained from the persistence Context cache, resulting in invalid data (step 3).

Vi. Solutions
My first thought was not to let the node type be cached, that is, add @cache (Type=cachetype.none) to the entity type. Although the problem is solved in this way, it brings about a decrease in efficiency. For example, node nodes have the method of acquiring whole tree data. The specific optimization scheme will be given in subsequent JPA follow-up articles.

Vii. Reference

Eclipselink Cache
Https://www.eclipse.org/eclipselink/documentation/2.5/concepts/cache001.htm

Eclipselink Source Address:
https://www.eclipse.org/eclipselink/downloads/previous_releases.php

Viii. Conclusion
Welcome everyone to spit groove, shoot bricks, correct ^_^

Jpa,eclipselink Caching mechanism Learning (a) Thinking of tree node search problem