The article directories

• One, foreword
• MyBatis cache overview
• Mybatis level 1 cache
• • 3.1 What is Level 1 Caching? Why level 1 caching?
  • 3.2 How is level 1 cache organized in SqlSession? (Class diagram organization +hashMap cache, completed)
  • 3.3 What is the life cycle of a Level 1 cache PerpetualCache? Three ways to end Level 1 Cache PerpetualCache (done)
  • 3.4 SqlSession Level 1 Cache workflow (build cacheKey+ query by cacheKey, completed)
  • 3.5 Bonus: Level 1 cache low-level design (very important, completed)
  • • 3.5.1 Two Functions of the CacheKey
    • 3.5.2 How can I determine the CacheKey? How can I tell if two queries are exactly the same?
    • 3.5.3 CacheKey Construction Algorithm (The BaseExecutor class createCacheKey() method)
    • 3.5.4 CacheKey HashCode Generation Algorithm (update())
  • 3.6 Performance analysis of level 1 cache and matters needing attention
  • • 3.6.1 Can I Use a CERTAIN SqlSession Object to Query Data All the time? If HashMap is Too Large, an OOM Error Occurs
    • 3.6.2 Level 1 cache is a Hashmap, no cache expiration, no cache updates
• Mybatis level 2 cache
• • 4.1 The overall design of cache mechanism of MyBatis and the working mode of two-level cache
  • 4.2 Mapper level 2 Operations (two types: one Mapper, one cache object + multiple Mapper, one cache object)
  • 4.3 Conditions for Using Level 2 Cache (Sql statement level operations in Level 2 Cache Mapper)
  • 4.4 Sequence of Level-1 cache and Level-2 Cache
  • 4.5 Three implementation modes of level 2 cache
  • 4.6 The first implementation: implementation of level 2 cache provided by MyBatis itself (10 level 2 cache implementation classes)
• How to fine-grained control your MyBatis level 2 cache (MyBatis enhanced Cache)
• • 5.1 A practical question about MyBatis level 2 cache
  • 5.2 Current working mechanism of MyBatis Level 2 Cache
  • 5.3 Design and working principle of mybatis-enhanced cache plug-in
  • • 5.3.1 EnhancedCachingExecutor artifacts
    • 5.3.2 EnhancedCachingManager artifacts
  • 5.4 Example of using the Mybatis -enhanced cache plug-in
• 6, interview goldfinger/talk about your understanding of MyBatis cache? (Interview recitation)
• • • 6.1 Level-1 cache and Level-2 Cache
    • 6.2 How level 1 Cache is organized (Class diagram organization +hashMap Cache)
    • 6.3 Lifecycle of Level-1 Cache PerpetualCache/End Four ways of Level-1 cache PerpetualCache
    • 6.4 Level-1 Cache Query Process
    • 6.5 Underlying design of level 1 Cache
    • 6.6 Level-2 Cache Operations at Mapper Level
    • 6.7 Level-2 Cache SQL statement-level operations and Level-2 Cache usage conditions (three)
    • 6.8 Cache Usage Sequence
    • 6.9 Three implementation modes of level 2 Cache
    • 6.10 The first implementation: the implementation of level 2 cache provided by MyBatis itself
• Seven, summary

One, foreword

MyBatis is a simple, compact but very powerful ORM open source framework, its powerful function is also reflected in its cache mechanism. MyBatis provides two cache mechanisms, level 1 cache and level 2 cache, which can well process and maintain the cache to improve the performance of the system.

ORM framework: Hibernate,Mybatis,Mybatis is smaller and lighter than Hibernate.

This article mainly explains the design principle of MyBatis very good cache mechanism, introduces the outline of the cache mechanism of MyBatis to the readers, and then discusses various aspects of the cache mechanism.

MyBatis cache overview

Mybatis level 1 cache

The purpose of this section is to introduce the level 1 cache of MyBatis to readers in detail, in-depth source code, analysis of the implementation principle of the level 1 cache of MyBatis, and for the characteristics of the level 1 cache in the actual use of matters that should be paid attention to.

3.1 What is Level 1 Caching? Why level 1 caching?

3.2 How is level 1 cache organized in SqlSession? (Class diagram organization +hashMap cache, completed)

Since MyBatis uses the SqlSession object to represent a database session, level 1 caching at the session level should also be controlled in SqlSession.

MyBatis is simply an interface to MyBatis, and SqlSession assigns its work to the Executor role, which is responsible for performing operations on the database. When a SqlSession object is created, MyBatis creates a new Executor Executor for the SqlSession object. The Cache information is maintained in this Executor Executor. MyBatis encapsulates the Cache and cache-related operations into the Cache interface.

The relationship between SqlSession, Executor, and Cache is shown in the following class diagram:

As shown in the class diagram above, the Implementation class of the Executor interface, BaseExecutor, has a PerpetualCache implementation class for the Cache interface. For a BaseExecutor object, it maintains the Cache using the PerpetualCache object.

To sum up, the relationship between SqlSession objects, Executor objects, and Cache objects is shown as follows:

Goldfinger: A session corresponds to a SqlSession, an Executor object, and a PerpetualCache object. The session ends and all disappear without persistency. The service stops and all disappear.

Since a Session level 1 cache is actually maintained using PerpetualCache, how is PerpetualCache implemented?

The implementation of PerpetualCache is simple, internally implemented with a simple HashMap<k,V>, no other restrictions.

PerpetualCache A so-called cache is just a hashmap 1, in memory, not persisted, stops the program cache disappearing. Hashmap, thread unsafe. Similarly, eureka-server’s two-layer map stores the service address list: 1. In memory, no persistence is carried out, and the stop program cache disappears. ConcurrentHashMap

>, outer ConcurrentHashMap, thread-safe.
,map

Here’s the implementation code for PerpetualCache:

package org.apache.ibatis.cache.impl; import java.util.HashMap; import java.util.Map; import java.util.concurrent.locks.ReadWriteLock; import org.apache.ibatis.cache.Cache; import org.apache.ibatis.cache.CacheException; @author Clinton Begin */ public class PerpetualCache implements Cache {private String id; private Map<Object, Object> cache = new HashMap<Object, Object>(); public PerpetualCache(String id) { this.id = id; } public StringgetId() {
    return id;
  }
 
  public int getSize() {
    return cache.size();
  }
 
  public void putObject(Object key, Object value) {
    cache.put(key, value);
  }
 
  public Object getObject(Object key) {
    return cache.get(key);
  }
 
  public Object removeObject(Object key) {
    return cache.remove(key);
  }
 
  public void clear() {
    cache.clear();
  }
 
  public ReadWriteLock getReadWriteLock() {
    return null;
  }
 
  public boolean equals(Object o) {
    if (getId() == null) throw new CacheException("Cache instances require an ID.");
    if (this == o) return true;
    if(! (o instanceof Cache))return false;
 
    Cache otherCache = (Cache) o;
    return getId().equals(otherCache.getId());
  }
 
  public int hashCode() {
    if (getId() == null) throw new CacheException("Cache instances require an ID.");
    returngetId().hashCode(); }}Copy the code

3.3 What is the life cycle of a Level 1 cache PerpetualCache? Three ways to end Level 1 Cache PerpetualCache (done)

3.4 SqlSession Level 1 Cache workflow (build cacheKey+ query by cacheKey, completed)

1. Build cacheKey: for a query, on the basis of statementId rowBounds, boundSql, params to build a key value (goldfinger: BaseExecutor createCacheKey in class () method), is cacheKey values.

2. Query by cacheKey: Cache results of fetching the corresponding key from the Cachkey Cache (Goldfinger: getObject() from BaseExecutor is invoked by the Query () method); Determine whether the data fetched from the Cache based on a specific key value is null, that is, hit (Goldfinger: query() method in BaseExecutor);

   (1) If a match is made, the cached result will be returned directly;

   (2) if lost: ① go to the database to query the data, get the query results; ② The key and the queried result are stored in the Cache as key and value pairs, respectively. ③ Return the query result.

Build cacheKey+ query from cacheKey

3.5 Bonus: Level 1 cache low-level design (very important, completed)

3.5.1 Two Functions of the CacheKey

A CacheKey does two things:

1. Cachekey is used as the key of a HashMap to find the Cache result (that is, a HashMap);
2. If the Cache fails to match, the cacheKey is removed from the database and written to the Cache to ensure that the Cache is hit next time. If the Cache fails to match, the cacheKey is used as the key and the result queried from the database is used as a value. The value pair is stored in the Cache.

3.5.2 How can I determine the CacheKey? How can I tell if two queries are exactly the same?

  <select id="selectByCritiera" parameterType="java.util.Map" resultMap="BaseResultMap">
        select employee_id,first_name,last_name,email,salary
        from louis.employees
        where  employee_id = #{employeeId}
        and first_name= #{firstName}
        and last_name = #{lastName}
        and email = #{email}
  </select>
Copy the code

select employee_id,first_name,last_name,email,salary
from louis.employees
where  employee_id = ?
and first_name= ?
and last_name = ?
and email = ?
Copy the code

3.5.3 CacheKey Construction Algorithm (The BaseExecutor class createCacheKey() method)

For each query request, Executor creates a Corresponding CacheKey object based on the parameters passed and dynamically generated SQL statements using the above conditions, which are the cacheKey construction algorithm and the unique signature of the CacheKey.

The CacheKey build is placed in the Executor interface implementation class BaseExecutor, defined as follows:

/ * * * belongs to class: org. Apache. Ibatis. Executor. BaseExecutor * function: CacheKey */ public CacheKey createCacheKey(MappedStatement MS, Object parameterObject, RowBounds RowBounds, BoundSql boundSql) {if (closed) throw new ExecutorException("Executor was closed."); Cachekey cachekey = new cachekey (); Cachekey.update (Ms. GetId ())) is provided in the MappedStatement object. //2. Rowbounds. offset and rowbounds. limit, arguments rowBounds object provides cacheKey.update(rowbounds.getoffset ()); cacheKey.update(rowBounds.getLimit()); BoundSql object provides cacheKey.update(boundSQL.getsQL ()); / / 4 parameters: Update each parameter value to be passed to JDBC to the CacheKey as well, Parameter parameterObject object provides a List < ParameterMapping > parameterMappings = boundSql. GetParameterMappings (); TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry();for (int i = 0; i < parameterMappings.size(); i++) { // mimic DefaultParameterHandler logic
      ParameterMapping parameterMapping = parameterMappings.get(i);
      if(parameterMapping.getMode() ! = ParameterMode.OUT) { Object value; String propertyName = parameterMapping.getProperty();if (boundSql.hasAdditionalParameter(propertyName)) {
          value = boundSql.getAdditionalParameter(propertyName);
        } else if (parameterObject == null) {
          value = null;
        } else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
          value = parameterObject;
        } else{ MetaObject metaObject = configuration.newMetaObject(parameterObject); value = metaObject.getValue(propertyName); } // Update each parameter value to be passed to JDBC to cachekey.update (value) in CacheKey; }} // After setting the cacheKey's unique signature, done, returnsreturn cacheKey;
  }    
Copy the code

The createCacheKey() method determines the unique signature of the CacheKey. The four cachekey parameters are provided by the four parameters of createCacheKey(). The MappedStatement provides the statementId. ParameterObject provides SQL parameters, RowBounds provides paging filtering conditions, and BoundSql provides dynamic SQL.

3.5.4 CacheKey HashCode Generation Algorithm (update())

  public void update(Object object) {
    if(object ! = null && object.getClass().isArray()) { int length = Array.getLength(object);for(int i = 0; i < length; i++) { Object element = Array.get(object, i); doUpdate(element); }}else{ doUpdate(object); } } private void doUpdate(Object object) { //1. Get the hashcode of the object; int baseHashCode = object == null ? 1 : object.hashCode(); //2. The object count is incremented, and the hashcode of the object is expanded by count times count++; checksum += baseHashCode; baseHashCode *= count; HashCode = multiplier * hashCode + baseHashCode; hashCode = multiplier * hashCode + baseHashCode; updateList.add(object); }Copy the code

3.6 Performance analysis of level 1 cache and matters needing attention

I will discuss SqlSession level 1 cache performance in terms of two level 1 cache features:

3.6.1 Can I Use a CERTAIN SqlSession Object to Query Data All the time? If HashMap is Too Large, an OOM Error Occurs

3.6.2 Level 1 cache is a Hashmap, no cache expiration, no cache updates

2. Level 1 cache is a coarse-grained cache with no concepts of cache update and cache expiration

MyBatis uses a simple HashMap for level 1 cache. MyBatis is only responsible for storing the results of the query database in the cache. It does not determine whether the cache is too long or expired, so there is no update of the cache results.

According to the characteristics of level 1 cache, I think we should pay attention to: 1, for the data change frequency is very large, and the need for high accuracy of the data requirements, we use SqlSession query, to control the SqlSession survival time, SqlSession survival time is longer, it is possible that the cache of data is older, resulting in and real database error; In this case, the user can also manually clear the CACHE in the SqlSession.

2. For SqlSession objects that only perform and frequently perform large select operations, the LIFETIME of the SqlSession object should not be too long.

For example:

SQL > select * from SqlSession; SQL > select * from SqlSession; SQL > select * from SqlSession

package com.louis.mybatis.test; import java.io.InputStream; import java.util.Date; import java.util.HashMap; import java.util.List; import java.util.Map; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.apache.ibatis.executor.BaseExecutor; import org.apache.ibatis.io.Resources; import org.apache.ibatis.session.SqlSession; import org.apache.ibatis.session.SqlSessionFactory; import org.apache.ibatis.session.SqlSessionFactoryBuilder; import org.apache.log4j.Logger; import com.louis.mybatis.model.Employee; @author louluan */ public class SelectDemo1 {private static final Logger loger = Logger.getLogger(SelectDemo1.class); public static void main(String[] args) throws Exception { InputStream inputStream = Resources.getResourceAsStream("mybatisConfig.xml"); SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder(); SqlSessionFactory factory = builder.build(inputStream); SqlSession sqlSession = factory.openSession(); Params = new HashMap<String,Object>(); params.put("min_salary", 10000); Date first = new Date(); List<Employee> result = sqlsession.selectList ("com.louis.mybatis.dao.EmployeesMapper.selectByMinSalary",params);
		loger.info("first quest costs:"+ (new Date().getTime()-first.getTime()) +" ms");
		Date second = new Date();
		result = sqlSession.selectList("com.louis.mybatis.dao.EmployeesMapper.selectByMinSalary",params);
		loger.info("second quest costs:"+ (new Date().getTime()-second.getTime()) +" ms"); }}Copy the code

Running results:

As you can see from the above results, the first query takes 464ms, while the second query takes less than 1ms, this is because after the first query, MyBatis will store the query result in the cache of SqlSession object, when the same query later, directly from the cache.

Select params (HashMap), params (HashMap), params (HashMap), params (HashMap);

As a result, the cache of the first query was pulled from the level 1 cache, even though the params parameters passed in the second query were inconsistent.

At this point, let the reader know this question:

MyBatis does not mean that all parameters passed to the Session are exactly the same. You just need to ensure that the SQL statement generated by statementId, rowBounds, And the parameters required by the SQL statement are exactly the same.

Not all parameters are the same, but all dynamically generated SQL requires the same parameters.

Mybatis level 2 cache

4.1 The overall design of cache mechanism of MyBatis and the working mode of two-level cache

MyBatis’ second-level caching mechanism is based on an Executor object that is used by a SqlSession object to perform session operations when opening a session, as shown above. If cacheEnabled=true is configured, MyBatis will add a decorator to the Executor object when creating it for the SqlSession object: CachingExecutor, in which case the SqlSession uses the CachingExecutor object to complete the operation request. CachingExecutor checks whether the query request has a cached result in the level-2 cache of the Application level. If yes, the CachingExecutor returns the cached result directly. If not, the actual Executor object is used to perform the query. CachingExecutor then places the query result returned by the real Executor into the cache and returns it to the user.

CachingExecutor is an Executor decorator to enhance the Executor by caching queries, using the decorator pattern in the design pattern,

The relationship between CachingExecutor and Executor’s interface is shown in the following class diagram:

4.2 Mapper level 2 Operations (two types: one Mapper, one cache object + multiple Mapper, one cache object)

4.3 Conditions for Using Level 2 Cache (Sql statement level operations in Level 2 Cache Mapper)

MyBatis support for level 2 caching is fine-grained, specifying whether a particular query statement in xxxmapper.xml uses level 2 caching.

Although Mapper is configured and Cache objects are allocated to the Mapper, this does not mean that the results of the query defined in Mapper will be placed in the Cache object. We must specify whether a select statement in Mapper supports caching, as shown below. When useCache is set to true on the node, Mapper supports caching for the Select query. Otherwise, the Select query does not pass the Cache. If the Select statement is set to useCache= “true” as shown below, the Select statement will use level 2 caching.

 <select id="selectByMinSalary" resultMap="BaseResultMap" parameterType="java.util.Map" useCache="true">
Copy the code

Level 2 cache support is fine-grained and specifies whether a particular query statement in xxxmapper.xml uses level 2 cache

In summary, to enable a Select query to support level 2 caching, you need to ensure three things:

1. MyBatis supports the master switch for level 2 caching: the global configuration variable parameter cacheEnabled=true
2. Mapper. XML level: The Mapper of the select statement is configured with or nodes and is valid
3. SQL level in mapper.xml: The parameter of the select statement useCache=true

Summary: Conditions for using level 2 cache (three) :

1. MyBatis supports the master switch for level 2 caching: cacheEnabled=true;
2. Mapper. XML level: The Mapper where the select statement resides is configured with or nodes and valid.
3. SQL level in mapper.xml: The parameter of the select statement useCache=true.

4.4 Sequence of Level-1 cache and Level-2 Cache

4.5 Three implementation modes of level 2 cache

MyBatis is very flexible in the design of level 2 cache,

First, it internally implements a series of Cache implementation classes and provides various Cache refresh strategies such as LRU, FIFO, etc.

Second, MyBatis also allows users to customize the Cache implementations of the interface, the user is the need to implement org. Apache. Ibatis. Cache. The Cache interface, then the Cache implementation class configuration on the type attribute of the node;

MyBatis also supports integration with third-party memory caching libraries such as Memecached. In short, there are three options for using MyBatis level 2 cache:

(1) Cache implementation provided by MyBatis itself;

(2) User-defined Cache interface implementation;

(3) Integration with third-party memory cache libraries;

Summary: Three implementation methods of level 2 cache: (1) Cache implementation provided by MyBatis; (2) User-defined Cache interface implementation; (3) Integration with third-party memory cache libraries;

4.6 The first implementation: implementation of level 2 cache provided by MyBatis itself (10 level 2 cache implementation classes)

How to fine-grained control your MyBatis level 2 cache (MyBatis enhanced Cache)

This part analyzes the deficiencies of the existing MyBatis level 2 cache step by step, discusses some improvements, and develops a plug-in to make up for the deficiencies.

5.1 A practical question about MyBatis level 2 cache

<select id="selectATableWithJoin" resultMap="BaseResultMap" useCache="true">
      select * from ATable left join BTable on ....
</select>
Copy the code

5.2 Current working mechanism of MyBatis Level 2 Cache

Current MyBatis level 2 cache working mechanism:

An important feature of MyBatis level 2 Cache: loose Cache management and maintenance.

Add, delete, modify, and query operations defined in a Mapper affect only the Cache objects associated with it. For several CRUD statements defined in Mapper Namespace1, as shown above, the resulting cache is only placed in the corresponding associated Cache1. The Mapper namespace2 namespace3, the CRUD statements will not affect the Cache1 namespace4.

It can be seen that the cache relationship between Mapper is loose and the degree of correlation is weak.

If the AMapper and BMapper share the same Cache object, then when the BMapper performs the update operation, it can clear all the cached data in the corresponding Cache. In this way, the data can also be kept up to date.

Yes, this is a solution, but it makes caching very inefficient! Any update operation of AMapper and BMapper will empty the shared Cache. The Cache will be emptied frequently, resulting in low Cache hit ratio and usage. Therefore, this strategy is not recommended in practice.

The ideal solution is:

How to clear the cache caused by the query statements associated with some tables after performing update (UPDATE, delete, INSERT) operations;

In this way, the internal cache of MyBatis is managed with very fine granularity, which greatly improves the utilization rate and accuracy of cache.

Based on this idea, I wrote a corresponding Mybatis -enhanced cache plug-in, which can well support the above functions.

For the example above, the plug-in can specify that the cache generated in ACache by the selectATableWithJoin query associated with the BTable is cleared when the BMapper performs an update operation on the BTable.

Let’s take a look at the design principles of mybatis-enhanced cache.

5.3 Design and working principle of mybatis-enhanced cache plug-in

5.3.1 EnhancedCachingExecutor artifacts

EnhancedCachingExecutor is an Executor interceptor that intercepts several key Executor methods.

EnhancedCachingExecutor does the following things:

1. Whenever an Executor executes a Query operation,

(1) record the query StatementId and CacheKey, and add them to the EnhancedCachingManager;

(2) record the query StatementId and the Cache object reference in the Mapper to which this StatementId belongs, and add it to EnhancedCachingManager;

2. Each time the Executor performs an update, it passes the StatementId of the update to the EnhancedCachingManager, and has the EnhancedCachingManager, based on the StatementId configuration of the update, To clear the cache generated by the specified query statement;

5.3.2 EnhancedCachingManager artifacts

5.4 Example of using the Mybatis -enhanced cache plug-in

1. Download the mybatis-enhanced Cache. rar package, decompress it, and add mybatis-enhanced Cache-0.0.1 – snapshot. jar to the classpath of the project.
2. Configure the MyBatis profile as follows:

  <plugins>
       <plugin interceptor="org.luanlouis.mybatis.plugin.cache.EnhancedCachingExecutor">
          <property name="dependency" value="dependencys.xml"/>
          <property name="cacheEnabled" value="true"/>
       </plugin>
  </plugins>
Copy the code

Where, the value attribute in is the configuration file path of the dependency between StatementId.

3. Configure the dependency relationship between StatementId

<? xml version="1.0" encoding="UTF-8"? > <dependencies> <statements> <statement id="com.louis.mybatis.dao.DepartmentsMapper.updateByPrimaryKey">
          <observer id="com.louis.mybatis.dao.EmployeesMapper.selectWithDepartments" />
       </statement>
   </statements>
</dependencies>
Copy the code

The node is configured with the statementId of the update statement, and its children are configured with the statementId of the query statement that should be cleared from the cache when the update statement is executed. There can be multiple child nodes.

As the configuration of the show, if “com. Louis. Mybatis. Dao. DepartmentsMapper. UpdateByPrimaryKey” update statement execution, By “com. Louis. Mybatis. Dao. EmployeesMapper. SelectWithDepartments” statements generated by the data will be placed in the Cache Cache is cleared.

4. Configure departmentSmapper. XML and employeesmapper.xml

DepartmentsMapper.xml

<? xml version="1.0" encoding="UTF-8"? > <! DOCTYPE mapper PUBLIC"- / / mybatis.org//DTD Mapper / 3.0 / EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd" >
<mapper namespace="com.louis.mybatis.dao.DepartmentsMapper" >
   
   <cache></cache>
 
  <resultMap id="BaseResultMap" type="com.louis.mybatis.model.Department" >
    <id column="DEPARTMENT_ID" property="departmentId" jdbcType="DECIMAL" />
    <result column="DEPARTMENT_NAME" property="departmentName" jdbcType="VARCHAR" />
    <result column="MANAGER_ID" property="managerId" jdbcType="DECIMAL" />
    <result column="LOCATION_ID" property="locationId" jdbcType="DECIMAL" />
  </resultMap>
  
  
  <sql id="Base_Column_List" >
    DEPARTMENT_ID, DEPARTMENT_NAME, MANAGER_ID, LOCATION_ID
  </sql>
  
  <update id="updateByPrimaryKey" parameterType="com.louis.mybatis.model.Department" >
    update HR.DEPARTMENTS
    set DEPARTMENT_NAME = #{departmentName,jdbcType=VARCHAR},
      MANAGER_ID = #{managerId,jdbcType=DECIMAL},
      LOCATION_ID = #{locationId,jdbcType=DECIMAL}
    where DEPARTMENT_ID = #{departmentId,jdbcType=DECIMAL}
  </update>
    <select id="selectByPrimaryKey" resultMap="BaseResultMap" parameterType="java.lang.Integer" >
    select 
    <include refid="Base_Column_List" />
    from HR.DEPARTMENTS
    where DEPARTMENT_ID = #{departmentId,jdbcType=DECIMAL}
  </select>
</mapper>
Copy the code

EmployeesMapper.xml

<? xml version="1.0" encoding="UTF-8"? > <! DOCTYPE mapper PUBLIC"- / / mybatis.org//DTD Mapper / 3.0 / EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.louis.mybatis.dao.EmployeesMapper">
 
  <cache eviction="LRU" flushInterval="100000" size="10000"/>
 
  <resultMap id="BaseResultMap" type="com.louis.mybatis.model.Employee">
    <id column="EMPLOYEE_ID" jdbcType="DECIMAL" property="employeeId" />
    <result column="FIRST_NAME" jdbcType="VARCHAR" property="firstName" />
    <result column="LAST_NAME" jdbcType="VARCHAR" property="lastName" />
    <result column="EMAIL" jdbcType="VARCHAR" property="email" />
    <result column="PHONE_NUMBER" jdbcType="VARCHAR" property="phoneNumber" />
    <result column="HIRE_DATE" jdbcType="DATE" property="hireDate" />
    <result column="JOB_ID" jdbcType="VARCHAR" property="jobId" />
    <result column="SALARY" jdbcType="DECIMAL" property="salary" />
    <result column="COMMISSION_PCT" jdbcType="DECIMAL" property="commissionPct" />
    <result column="MANAGER_ID" jdbcType="DECIMAL" property="managerId" />
    <result column="DEPARTMENT_ID" jdbcType="DECIMAL" property="departmentId" />
  </resultMap>
 
  <sql id="Base_Column_List">
    EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_ID, SALARY, 
    COMMISSION_PCT, MANAGER_ID, DEPARTMENT_ID
  </sql>
  
  <select id="selectWithDepartments" parameterType="java.lang.Integer" resultMap="BaseResultMap" useCache="true" >
    select 
    *
    from HR.EMPLOYEES t left join HR.DEPARTMENTS S ON T.DEPARTMENT_ID = S.DEPARTMENT_ID
    where EMPLOYEE_ID = #{employeeId,jdbcType=DECIMAL}
  </select>
  
</mapper>
Copy the code

Level 2 cache uses three steps:

5. Test code:

package com.louis.mybatis.test; import java.io.InputStream; import java.util.Date; import java.util.HashMap; import java.util.Iterator; import java.util.List; import java.util.Map; import org.apache.ibatis.io.Resources; import org.apache.ibatis.session.SqlSession; import org.apache.ibatis.session.SqlSessionFactory; import org.apache.ibatis.session.SqlSessionFactoryBuilder; import org.apache.log4j.Logger; import com.louis.mybatis.model.Department; import com.louis.mybatis.model.Employee; @author louluan */ public class SelectDemo3 {private static final Logger loger = Logger.getLogger(SelectDemo3.class); public static void main(String[] args) throws Exception { InputStream inputStream = Resources.getResourceAsStream("mybatisConfig.xml");
		SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder();
		SqlSessionFactory factory = builder.build(inputStream);
		
		SqlSession sqlSession = factory.openSession(true);
		SqlSession sqlSession2 = factory.openSession(true); Params = new HashMap<String,Object>(); params.put("employeeId", 10); Date first = new Date(); List<Employee> result = sqlsession.selectList ("com.louis.mybatis.dao.EmployeesMapper.selectWithDepartments",params); sqlSession.commit(); checkCacheStatus(sqlSession); // first check // second query params.put("employeeId"11); result = sqlSession.selectList("com.louis.mybatis.dao.EmployeesMapper.selectWithDepartments",params); sqlSession.commit(); checkCacheStatus(sqlSession); // query params.put(params."employeeId", 12);
        result = sqlSession.selectList("com.louis.mybatis.dao.EmployeesMapper.selectWithDepartments",params); sqlSession.commit(); checkCacheStatus(sqlSession); Params. Put (params."employeeId", 13);
        result = sqlSession.selectList("com.louis.mybatis.dao.EmployeesMapper.selectWithDepartments",params); sqlSession.commit(); checkCacheStatus(sqlSession); Department Department = sqlsession.selectOne ()"com.louis.mybatis.dao.DepartmentsMapper.selectByPrimaryKey", 10); department.setDepartmentName("updated");
		sqlSession2.update("com.louis.mybatis.dao.DepartmentsMapper.updateByPrimaryKey", department); sqlSession.commit(); checkCacheStatus(sqlSession); } public static void checkCacheStatus(SqlSession SqlSession) {loger.info("------------Cache Status------------");
		Iterator<String> iter = sqlSession.getConfiguration().getCacheNames().iterator();
		while(iter.hasNext())
		{
			String it = iter.next();
			loger.info(it+":"+sqlSession.getConfiguration().getCache(it).getSize());
		}
		loger.info("-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -"); }}Copy the code

Result output:

Results analysis:

Can be seen from the above results, the first four times performed “com. Louis. Mybatis. Dao. EmployeesMapper. SelectWithDepartments” statement, The number of result caches stored in the EmployeesMapper Cache increases from 1 to 4.

When performing the “com. Louis. Mybatis. Dao. DepartmentsMapper. UpdateByPrimaryKey” after EmployeeMapper corresponding buffer Cache results are cleared, Or “com. Louis. Mybatis. Dao. DepartmentsMapper. UpdateByPrimaryKey” in the update statement caused EmployeeMapper “. Com. Louis. Mybatis. Dao EmployeesMapp Er. selectWithDepartments” cache cleanup.

6, interview goldfinger/talk about your understanding of MyBatis cache? (Interview recitation)

6.1 Level-1 cache and Level-2 Cache

MyBatis designs the data cache into a two-level structure, which is divided into first-level cache and second-level cache:

Level 1 cache granularity: coarse-grained, available to all requests, cacheKey is statementId + rowBounds + SQL passed to JDBC + parameter value passed to JDBC. Level 1 cache life cycle: short life cycle, end of session release, update release, manual release. Level 1 cache read operation: if hit, get out; if not hit, get out of the database and update the cache; Level 1 cache write operation: Direct release. Level 1 buffer application: 1, for the data change frequency is very large, and the need for high accuracy of the data requirements, we use SqlSession query, to control the SqlSession survival time, SqlSession survival time is longer, it is possible that the cache of data is older, resulting in and real database error; In this case, the user can also manually clear the CACHE in the SqlSession. 2. For SqlSession objects that only perform and frequently perform large select operations, the LIFETIME of the SqlSession object should not be too long.

Granularity of level 2 cache: Fine granularity. Each Mapper can only use its own level 2 cache. Each SQL statement determines whether to enable level 2 cache. The second level cache life cycle: long life cycle, the whole application/end release configuration. Level 2 cache read operation: if hit, get out; if not hit, get out of database and update cache; Level 2 cache write operations: Level 2 Cache application:

Add: Redis read operation: hit it out, not hit it out from the database and update the cache; Redis write operations: write direct and write back (redis is written on the next read request)

6.2 How level 1 Cache is organized (Class diagram organization +hashMap Cache)

6.3 Lifecycle of Level-1 Cache PerpetualCache/End Four ways of Level-1 cache PerpetualCache

Summary: Tier 1 cache lifecycle, three ways to end Tier 1 cache PerpetualCache: a.session.close () If a SqlSession calls close(), the session ends, the SqlSession object, its internal Executor object, and the PerpetualCache object are also released, i.e. the tier 1 cache is not available when the Tier 1 cache is freed; B. session.clearCache() method: If clearCache() is called by SqlSession, the data in the PerpetualCache object is cleared, but the object is still usable; Session.update (), session.delete(), session.insert() : Every UPDATE operation performed in SqlSession (update(), delete(), INSERT ()) clears data from the PerpetualCache object, but the object continues to be used;

6.4 Level-1 Cache Query Process

6.5 Underlying design of level 1 Cache

The CacheKey does two things: (1) a cache hit is pulled from a HashMap based on the CacheKey; (2) If the cache is not hit, the cacheKey is removed from the database and written to the cache to ensure that the cache is hit again. 2. Cachekey determination: StatementId + rowBounds + SQL passed to JDBC + parameter values passed to JDBC The four cacheKey parameters are provided by the four parameters of createCacheKey(), the MappedStatement provides the statementId, ParameterObject provides SQL parameters, RowBounds provides paging filtering criteria, and BoundSql provides dynamic SQL. Get the hashcode of the object; int baseHashCode = object == null ? 1 : object.hashCode(); //2. The object count is incremented, and the hashcode of the object is expanded by count times count++; checksum += baseHashCode; baseHashCode = count; HashCode = multiplier * hashCode + baseHashCode; hashCode = multiplier * hashCode + baseHashCode;

6.6 Level-2 Cache Operations at Mapper Level

6.7 Level-2 Cache SQL statement-level operations and Level-2 Cache usage conditions (three)

Summary: Conditions for using level 2 cache (three) :

1. MyBatis supports the master switch for level 2 caching: cacheEnabled=true;
2. Mapper. XML level: The Mapper where the select statement resides is configured with or nodes and valid.
3. SQL level in mapper.xml: The parameter of the select statement useCache=true.

6.8 Cache Usage Sequence

6.9 Three implementation modes of level 2 Cache

Summary: Three implementation methods of level 2 cache: (1) Cache implementation provided by MyBatis; (2) User-defined Cache interface implementation; (3) Integration with third-party memory cache libraries;

6.10 The first implementation: the implementation of level 2 cache provided by MyBatis itself

Seven, summary

Mybatis cache understanding, done.

Play code every day, progress every day!!