[Cache of Mybatis]

Many applications add caching to improve performance, especially for data fetched from databases. By default, mybatis's first level cache is enabled by default. Similar to hibernate, the so-called first-level cache is the query statement based on the same sqlsession, that is, the session-level cache, non-global cache, or non-second-level cache.

 

If you want to implement the second level cache of mybatis, there are generally two ways:

1. Use the cache mechanism built into mybatis.

2. Use a three-party cache framework, such as ehcache, oscache, etc.

 

Use mybatis built-in cache mechanism.

Add the <cache /> statement in the sql statement mapping file, and the corresponding model class should implement the java Serializable interface, because caching is the process of serialization and deserialization, so this interface needs to be implemented. Simple <cache /> means the following:

 

1. All select statements in the mapping file will be cached.

2. All insert, update and delete statements in the mapping file will clear the cache.

3. The cache is reclaimed using a "rarely recently used" algorithm

4. The cache will not be emptied by the set time.

5. Each cache can store 1024 references to lists or objects (regardless of the results of the query).

6. The cache will act as a "read/write" cache, meaning that fetched objects are not shared and are safe for the caller. There will be no potential modification by other callers or threads.

 

 

The first level cache of Mybatis refers to SqlSession. The scope of the first level cache is a SqlSession. Mybatis turns on the first level cache by default.

 

In the same SqlSession, the same query SQL is executed, the first time it will query the database and write it to the cache; the second time it will be directly fetched from the cache. When an addition, deletion or modification occurs between two queries when executing SQL, the cache of the SqlSession is cleared.



 Level 1 Cache Principle Level 2 Cache

  

The second level cache of Mybatis refers to the mapper mapping file. The scope of the second-level cache is the mapper mapping file content under the same namespace, which is shared by multiple SqlSessions. Mybatis needs to manually set up the second level cache.

 

In the mapper file under the same namespace, the same query SQL is executed. The first time it will query the database and write it to the cache; the second time it will be taken directly from the cache. When an addition, deletion or modification occurs between two queries when executing SQL, the second-level cache is emptied.



 



 

Permalink:  http://gaojingsong.iteye.com/blog/2335573

Preview article: Ibatis source code reading LruCacheController of LRU (least recently used) 

Permalink:  http://gaojingsong.iteye.com/blog/2335602

Preview article: Mybatis source code reading FIFO (FifoCache) 



 

Avoid using second level cache

There may be many people who don't understand this. The benefits of the second-level cache are far less than the hidden dangers.

The cache is based on the namespace, and operations under different namespaces do not affect each other.

 

The insert, update and delete operations will clear all caches under the namespace where they are located.

 

Usually in the code generated by MyBatis Generator, each table is independent, and each table has its own namespace.

 

Why Avoid L2 Cache

There is no harm when it meets the requirements of [Cautions when using Cache].

In other cases, there are many hazards.

 

Some operations on a table are not performed under its separate namespace.

 

For example, in UserMapper.xml there are most operations for the user table. But in a XXXMapper.xml, there are also operations for the user single table.

 

This will result in inconsistent user data in the two namespaces. If the operation of refreshing the cache is done in UserMapper.xml, the cache in XXXMapper.xml is still valid. If there is a single-table query for user, the result of using the cache may be incorrect.

 

A more dangerous situation is that when XXXMapper.xml performs insert, update, and delete operations, it will cause various operations in UserMapper.xml to be full of unknowns and risks.

 

Operations on such a single table may not be common. But you may be thinking of a common situation.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326909361&siteId=291194637