The caching mechanism of mybatis: the difference between the first level cache and the second level cache

Article Directory

https://www.cnblogs.com/yunianzeng/p/11826449.html


The caching mechanism of mybatis: the difference between the first-level cache and the second-level cache
(mosaic point:) The bottom layer of Sqlsession (interface) is hashmap storage, which is not thread-safe, and sqlsessionTemplate is thread-safe for its implementation class

Difference: The scope of the first level cache is within a sqlsession; the scope of the second level cache is for the mapper.

  • Level 1 cache:

1. Initiating a query for user information with user id 1 for the first time, first check whether there is user information with id 1 in the cache. If not, query the user information from the database. Obtain user information and store the user information in the first-level cache.

2. If the intermediate sqlSession performs commit operations (performs inserts, updates, deletes), the level one cache in the SqlSession will be cleared. The purpose of this is to keep the latest information stored in the cache and avoid dirty reads.

3. Initiating a second query for user information with user id 1, first check whether there is user information with id 1 in the cache, and if there is any user information in the cache, the user information is directly obtained from the cache.

Summary: Performing commit, close, adding, deleting, and modifying operations in the first level cache will clear the current first level cache; when the SqlSession update operation (update, delete, insert) is executed and the commit is executed, not only its own one is cleared Level cache (the effect of performing an update operation), and also clear the level two cache (the effect of executing commit()).

  • Secondary cache:

Regardless of whether it is the same session or not, as long as the mapper's namespace is the same, the cache may be shared. Requirements: If the second-level cache is turned on, then the data in the first-level cache of the sqlsession will be added to the namespace after the sqlsession is closed (close) In the secondary cache.

After the second level cache is enabled, the pojo to be cached also needs to implement the Serializable interface. In order to remove the cached data and perform the deserialization operation, because the second level cache data storage media is diverse, not necessarily only in the memory, there may be a hard disk in

Then in the same session, when the same select statement is executed, Cache Hit Ratio [Mapper]: 0.0, the hit rate of the secondary cache is 0?

Answer: I want to explain when the cache of the second-level cache is stored: only when the current session.close(), the data of the session will be stored in the second-level cache. In the same session, it must not be executed. Close() closes the session, and naturally it is not stored in the second-level cache. The second execution does not resend the SQL statement, because the second call is the data in the cache.

If you want the second-level cache hit rate to be non-zero, you need to first open a session, execute a SQL statement, then close the session, and then create a new session and execute the same SQL statement. At this time, the second-level cache will Hit.


Finish

Guess you like

Origin blog.csdn.net/baidu_21349635/article/details/108996694