Shulou(Shulou.com)06/02 Report--

This article mainly introduces the example analysis of Mybatis's first-level cache and second-level cache. It has certain reference value. Interested friends can refer to it. I hope you will gain a lot after reading this article. Let Xiaobian take you to understand it together.

Mybatis provides us with a level 1 cache and a level 2 cache, which can be understood by the following figure:

① Level 1 cache is a cache at SqlSession level. When operating the database, you need to construct sqlSession object, in which there is a data structure (HashMap) for storing cached data. The cache data area (HashMap) between different sqlSessions is independent of each other.

②. The secondary cache is a cache at the mapper level. Multiple SqlSessions operate the sql statement of the same Mapper. Multiple SqlSessions can share the secondary cache. The secondary cache is cross-SqlSession.

1. Level 1 cache ①. In a sqlSession, we query the User table twice according to id to see how they issue sql statements.@ Testpublic void testSelectOrderAndUserByOrderId(){ //generate session from sqlSessionFactory SqlSession sqlSession = sessionFactory.openSession(); String statement = "one.to.one.mapper.OrdersMapper.selectOrderAndUserByOrderID"; UserMapper userMapper = sqlSession.getMapper(UserMapper.class); //For the first query, issue sql statements and put the query results into the cache User u1 = userMapper.selectUserByUserId(1); System.out.println(u1); //The second query, because it is the same sqlSession, will find the query results in the cache //If there is one, it is taken directly from the cache and does not interact with the database. User u2 = userMapper.selectUserByUserId(1); System.out.println(u2); sqlSession.close();}

To view console printing:

②. The user table is also queried twice, but an update operation is performed between the two queries.@ Testpublic void testSelectOrderAndUserByOrderId(){ //generate session from sqlSessionFactory SqlSession sqlSession = sessionFactory.openSession(); String statement = "one.to.one.mapper.OrdersMapper.selectOrderAndUserByOrderID"; UserMapper userMapper = sqlSession.getMapper(UserMapper.class); //For the first query, issue sql statements and put the query results into the cache User u1 = userMapper.selectUserByUserId(1); System.out.println(u1); //The second step performs an update operation, sqlSession.commit() u1.setSex("female"); userMapper.updateUserByUserId(u1); sqlSession.commit(); //The second query, because it is the same sqlSession.commit(), will empty the cache information //this query will also issue sql statements User u2 = userMapper.selectUserByUserId(1); System.out.println(u2); sqlSession.close();}

Console printing:

3. Summary

1. Initiate a query for user information with user id 1 for the first time. First, find whether there is user information with id 1 in the cache. If there is no user information, query the user information from the database. obtaining user information, and storing the user information in a first-level cache.

2. If the intermediate sqlSession performs commit operations (insert, update, delete), the first-level cache in the SqlSession will be emptied. The purpose of this is to make the cache store the latest information and avoid dirty reading.

3. Initiate a second query for user information with user id 1, and first find out whether there is user information with id 1 in the cache. If there is user information with id 1 in the cache, obtain user information directly from the cache.

2. Level 2 cache

The principle of the second level cache is the same as that of the first level cache. The first query will put the data into the cache, and then the second query will directly fetch it from the cache. However, the first level cache is based on sqlSession, while the second level cache is based on the namespace of the mapper file, that is to say, multiple sqlSessions can share the second level cache area in a mapper, and if the namespaces of two Mappers are the same, even if it is two Mappers, then the data queried by SQL in these two Mappers will also exist in the same second level cache area.

So how is L2 cache used?

① Open the second level cache

Different from the first cache default, the second cache needs to be manually enabled.

First add the following code to the global configuration file mybatis-configuration.xml:

Second, turn on caching in the UserMapper.xml file

We can see that mapper.xml file on such an empty tag, in fact, here you can configure PerpetualCache this class is mybatis default implementation of caching function class. We don't write type to use mybatis default cache, or we can implement Cache interface to customize cache.

We can see whether the L2 cache layer is still HashMap architecture.

②. po class implements Serializable serialization interface

After the L2 cache is enabled, it is also necessary to implement the Serializable interface for the pojo to be cached. In order to retrieve the cached data, the deserialization operation is performed. Because the L2 cache data storage medium is various, it may not only exist in memory, but may exist in the hard disk. If we want to retrieve this cache again, we need to deserialize it. So the pojo in mybatis implements the Serializable interface.

③ Test

First, test level 2 cache and sqlSession independent

@Testpublic void testTwoCache(){ //generate session from sqlSessionFactory SqlSession sqlSession1 = sessionFactory.openSession(); SqlSession sqlSession2 = sessionFactory.openSession(); String statement = "com.ys.twocache.UserMapper.selectUserByUserId"; UserMapper userMapper1 = sqlSession1.getMapper(UserMapper.class); UserMapper userMapper2 = sqlSession2.getMapper(UserMapper.class); //For the first query, issue sql statements and put the query results into the cache User u1 = userMapper1.selectUserByUserId(1); System.out.println(u1); sqlSession1.close();//Close sqlSession after first query //the second query, even if sqlSession1 has been closed, this query still does not issue sql statements User u2 = userMapper2.selectUserByUserId(1); System.out.println(u2); sqlSession2.close();}

You can see that the above two different sqlSessions, the first closed, the second query still does not issue sql query statements.

Second, the test performs the commit() operation, and the secondary cache data is cleared.

@Testpublic void testTwoCache(){ //generate session from sqlSessionFactory SqlSession sqlSession1 = sessionFactory.openSession(); SqlSession sqlSession2 = sessionFactory.openSession(); SqlSession sqlSession3 = sessionFactory.openSession(); String statement = "com.ys.twocache.UserMapper.selectUserByUserId"; UserMapper userMapper1 = sqlSession1.getMapper(UserMapper.class); UserMapper userMapper2 = sqlSession2.getMapper(UserMapper.class); UserMapper userMapper3 = sqlSession2.getMapper(UserMapper.class); //For the first query, issue sql statements and put the query results into the cache User u1 = userMapper1.selectUserByUserId(1); System.out.println(u1); sqlSession1.close();//Close sqlSession after first query //perform update operation, commit() u1.setUsername("aaa"); userMapper3.updateUserByUserId(u1); sqlSession3.commit(); //The second query, due to the last update operation, the cache data has been emptied (to prevent dirty data reading), here you must issue sql statements again User u2 = userMapper2.selectUserByUserId(1); System.out.println(u2); sqlSession2.close();}

To view the console:

④, useCache and flushCache

Mybatis can also configure configuration items such as userCache and flushCache. UserCache is used to set whether to disable L2 cache. Setting useCache=false in statement can disable L2 cache of current select statement, that is, sql will be issued for each query. The default is true, that is, the sql uses L2 cache.

select * from user where id=#{id}

This situation is for each query requires the latest data sql, to set useCache=false, disable the secondary cache, directly from the database.

In the same namespace of the mapper, if there are other insert, update, delete operations, the cache needs to be flushed, and if the cache is not flushed, dirty reads will occur.

Set the flushCache="true" attribute in the statement configuration. By default, it is true, that is, the cache is refreshed. If it is changed to false, it will not be refreshed. Dirty reads occur when caching is used if query data in database tables is manually modified.

select * from user where id=#{id}

In general, the commit operation needs to be flushed, flushCache=true means flushing the cache, so as to avoid dirty database reading. So we don't have to set it up, we can default.

Thank you for reading this article carefully. I hope that the article "Example Analysis of Level 1 Cache and Level 2 Cache in Mybatis" shared by Xiaobian will be helpful to everyone. At the same time, I hope that everyone will support you a lot and pay attention to the industry information channel. More relevant knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.