Mybatis first level cache and second level cache understanding

Persistence layer framework: Mybatis

Mybatis provides query cache divided into first level cache and second level cache, which are used to reduce database pressure and improve database performance.

How the first level cache works

The first level cache is the SqlSession level cache

  The first level query cache of MyBatis is implemented by the HashMap local cache of the org.apache.ibatis.cache.impl.PerpetualCache class. Its scope is SqlSession, and its scope is the life cycle. If executed in the same SqlSession In the two SQL statement queries, the positions of the two queries are different. In the first query, because there is no cached result, the query result is performed from the database. After the result is obtained, the result is written to the cache and the result is returned to the query statement , And when the second query is made, there are already qualified result sets in the cache. This time the query will get the results in the cache and return them instead of querying the database. When the SqlSession ends, the corresponding cache is destroyed. MyBatis is turned on by default during the first level query, and it cannot be turned off.

How the second-level cache works

The second-level cache is different from the first-level cache in that it is more powerful. Its life cycle is longer than that of the first-level cache. The life-cycle of the second-level cache is synchronized with the entire application, living and dying with the application. At this time, the second-level cache The cache has nothing to do with SqlSession. This is from the life cycle of the two of them, in addition to their different purposes, the first level cache is used to share data to improve speed and efficiency, while the second level cache is to extend the query results Save time, thereby improving system performance, the second-level cache can also be used to share data. 
       The second level cache is built-in in myBatis, and its implementation class is org.apache.ibatis.cache.impl.PerpetualCache, and the entity class needs to implement the serialization interface when using it. In addition to the built-in, there is also an ehcache, which is relative to This is professional in terms of the built-in cache, and it is more convenient to use.

The secondary cache of mybatis is at the level of the mapper range. Set the general switch of the secondary cache in sqlMapperConfig, and then turn on the secondary cache in the specific mapper.

sqlSession1 queries the user information whose user id is 1, and stores the query data in the secondary cache when the user information is queried.

sqlSession2 queries the user information with the user id of 1, to find whether there is data in the cache, and if there is data, it directly fetches the data from the cache.

 

the difference:
 

The second-level cache is different from the first-level cache. The second-level cache has a larger scope, because multiple sqlSessions can share the same second-level cache area.

UserMapper has a secondary cache area (differentiated by namespace), and other mappers (differentiated by namespace) also have their own secondary cache area

Each namespace mapper has a second-level cache area. If the namespaces of two mappers are the same, the data queried by the two mappers executing SQL will be stored in the same second-level cache area.

Important attributes in the
cache Disable the second-level cache
Setting useCachefalse in the statement can disable the second-level cache of the current select statement, that is, each query will issue SQL to query, the default is true, that is, the SQL uses the second-level cache.

<select id=”findUserById” resultMap=”BaseResultMap” useCache=”false”>

Summary: For each query, the latest data is required, and it needs to be set to useCache=”false” to disable the second-level cache

Refresh the cache (that is, clear the cache)
If there are other insert, update, and delete operations in the same namespace of the mapper, the cache needs to be refreshed. If you do not refresh the cache, dirty reads will occur.

Set the flushCache=”true” attribute in the statement configuration. By default, it is true to refresh the cache, and if it is changed to false, it will not be refreshed. When using the cache, if you manually modify the query data in the database table, dirty reads will occur.
 

Application scenarios of secondary cache

Rarely modified data

Not very important data, allowing occasional concurrent data

Data that will not be accessed concurrently

Commonly used cache plugins

EhCache: It can be used as a process-wide cache. The physical medium for storing data can be memory or hard disk, which provides support for Hibernate's query cache.

redis: is a key-value storage system. Similar to Memcached, it supports relatively more value types for storage, including string (string), list (linked list), set (collection), zset (sorted set - ordered collection) and hash (hash type)

 

The typical application scenarios of distributed caching can be divided into the following categories:
Page caching. It is used to cache the content fragments of Web pages, including HTML, CSS and pictures, etc., which are mostly used in social networking sites.
Application object caching. The caching system is used as an ORM framework. The second-level cache provides services to the outside world with the purpose of reducing the load pressure of the database and accelerating application access;
state caching. The cache includes Session session state and state data when the application is scaled out. This type of data is generally difficult to recover and requires availability. High, mostly used in high-availability clusters;
parallel processing. Usually involves a large number of intermediate calculation results that need to be shared;
event processing. Distributed cache provides continuous query processing technology for event streams to meet real-time requirements;
extreme transactions Processing. Distributed cache provides high throughput and low latency solutions for transactional applications, supports high concurrent transaction request processing, and is mostly used in railways, financial services, and telecommunications.

Guess you like

Origin blog.csdn.net/A___B___C/article/details/83717288