MyBatis deferred load and query caching

One, delayed loading

Resultmap can implement advanced Mapping (using association, collection for one-to-one and one-to-many mappings), association and collection have lazy loading capabilities.

Lazy loading: The first query from a single table, and then from the association table to correlate the query, greatly improve the database performance, because the query table is more than the associated query table speed faster.

Configure in the MyBatis core configuration file:

Lazyloadingenabled, aggressivelazyloading

Setting items	Describe	Allowed values	Default value
la zyloadingenabled		true | false	false
ag gressivelazyloading		true | false	true

< Settings >      <  name= "lazyloadingenabled"  value= "true"/>       <name= "aggressivelazyloading"  value= "false" /> </ Settings >

Occasion:

When only some of the records need to be associated with querying other information, you can defer loading on demand at this time, and then issue SQL to the database when you need to correlate the queries to improve database performance.

When all need to correlate the query information, at this time do not delay loading, directly the association query information to return all, you can use Resulttype or Resultmap to complete the mapping.

Second, query cache

MyBatis provides query caching to reduce data pressure and increase database pressure.

MyBatis provides a first-level cache and a level two cache.

　　

The Sqlsession object needs to be constructed when manipulating the database, and there is a data structure (HASHMAP) in the object to cache the data.

The cache data regions between different sqlsession are not affected by each other.

MyBatis cache scope is the same sqlsession, two times in the same sqlsession executes the same SQL statement, the first execution will be the database query data written to the cache (memory), the second time from the cache will not be retrieved from the database query, Thus improve query efficiency. The first-level cache in the sqlsession does not exist when a sqlsession is finished. MyBatis first-level caching is turned on by default.

MyBatis level Two caches are shared by multiple sqlsession and are scoped to the same namespace of mapper, Different sqlsession Execute SQL statements under the same namespace two times and pass parameters to SQL in the same way that the same SQL statement is eventually executed, the first execution will write the data queried in the database to the cache (memory), and the second time the data from the cache will no longer be queried from the database , thus improving query efficiency. MyBatis no two cache is enabled by default and needs to be configured to turn on level two cache in the setting global parameter.

1, first-level cache

　　

The first time you start a query, go to the cache to see if there is an ID of 1 user information, if not, query the user information from the database.

Get the user information and store the user information in the first level cache.

The second launch of the query user ID 1 user information, first go to the cache if there is ID 1 user information, the cache has, directly from the cache to obtain user information.

If sqlsession to perform a commit operation (INSERT, UPDATE, delete), empty the first-level cache in the sqlsession. The goal is to keep the cache up-to-date with the latest information and avoid dirty reads.

MyBatis supports first-level caching by default and does not need to be configured in the configuration file.

　　The MyBatis internal storage cache uses a hashmap,key as a hashcode+sqlid+sql statement. Value is the Java object generated from the query-out mapping.

　　Application Scenarios:

　　

2, Level two cache

　　

SqlSession1 to query User ID 1, query to user information will store the query data in the level two cache.

SqlSession2 to query the user ID 1 user information, go to the cache to find out if there is data, if there is directly from the cache to remove data.

The secondary cache area is divided according to the namespace of the Mapper, and the same namespace mapper query data is placed in the same region, if Mapper proxy method is used, each mapper namespace is different. At this point it can be understood that the level two cache area is divided by mapper.

Each query is first looked up from the cache area, and if no query is found from the database, the query to the data writes the data to the cache.

The MyBatis internal storage cache uses a hashmap,key as a hashcode+sqlid+sql statement. Value is the Java object generated from the query-out mapping

Sqlsession performs insert, UPDATE, Delete, and so on commits to empty the cache area after commit commit.

　　turn on level two caching :

Add in core profile Sqlmapconfig.xml

<name= "cacheenabled"  value= "true"/>

cacheenabled

	description	allowable value
	true false	true

To add a line to your mapper mapping file: <cache/>, this mapper turns on level two caching.

　　The secondary cache requires the Pojo object of the query result map to implement the Java.io.Serializable interface for serialization and deserialization operations, noting that if there is a parent class, the member Pojo needs to implement the serialization interface.

　　In order to take out the cached data for deserialization, because the level two cache storage media is varied, it is not necessarily in memory.

　　Disable Level Two caching :

　　Setting Usecache=false in statement disables the level two cache of the current SELECT statement, that is, each query emits a SQL query, which by default is true, that is, the SQL uses a level two cache.

<select id= "Findorderlistresultmap" resultmap= "Ordersusermap" usecache= "false" >

　　flush the cache (that is, empty the cache):

Setting the Flushcache= "true" property in the statement configuration, which is true by default, refreshes the cache and does not refresh if it is changed to false. When you use caching, dirty reads occur if you manually modify the query data in a database table.

<insert id= "Insertuser" parametertype= "Cn.itcast.mybatis.po.User" flushcache= "true" >

　　Application Scenarios :

　　for access to many query requests and users of query results real-time requirements are not high, at this time can use MyBatis two cache technology to reduce database access , improve access speed, business scenarios such as: time-consuming statistical analysis of SQL, telephone Bill query SQL.

The implementation is as follows: By setting the refresh interval, the cache is automatically emptied by mybatis at intervals, and the cache refresh interval is set according to the data change frequency flushinterval, for example, set to 30 minutes, 60 minutes, 24 hours, etc., depending on the needs.

　　Limitations :

　　MyBatis level Two cache for fine-grained data-level cache implementation is not good , such as the following requirements: The product information cache, because the product information query access is large, but require users every time can query the latest product information, At this point, if you use MyBatis's level two cache, you cannot realize that when a commodity changes, only the cache information of the product is refreshed and the information of other goods is not refreshed, because Mybaits's level two cache area is divided by mapper, and when an item information changes, the cached data of all commodity information is emptied. Addressing such issues requires a targeted cache of data at the business level based on demand.

MyBatis deferred load and query caching