Ibatis Learning Summary 4--sql map XML Map file extension

The SQL map XML map file has some other important properties in addition to the attributes mentioned above, which are described in detail later in this article.

• Cache Mapped Statement result set

  You can cache query results from Mapped statement by specifying the Cachemodel property in query statement. The cache model is a configurable cache mode defined in the SQL Map XML file and can be configured using the Cachemodel element.

  1 <CachemodelID= "Product-cache"type= "LRU"readOnly= "true"Serialize= "false" >2 <flushinterval hours= "+"/>
  3 <FlushonexecuteStatement= "Insertproduct"/>
  4 <FlushonexecuteStatement= "UpdateProduct"/>
  5 <FlushonexecuteStatement= "Deleteproduct"/>
  6 < Propertyname= "Cache-size"value= "+"/>
  7 </Cachemodel>

  The cache model above creates a buffer named "Product-cache", using the "least Recently used" (LRU) implementation. The name of the Implemention property is either a fully qualified class name or an alias for the cache implementation (see below). Based on the contents of the flush element in Cachemodel, the above example is refreshed every 24 hours. An cachemodel can have only one flushinteval element, which can be set using hours,minutes,seconds or milliseconds. Also, the cache is refreshed when insertproduct,updateproduct or Deleteproduct's Mapped Statement is executed. Cachemodel can define any number of flushonexecute elements. Some implementations of the cache model may require additional attributes, such as the "Cache-size" attribute above. In the LRU cache model, cache-size specifies the number of items that the cache stores. Once the cache model is configured, you can specify the cache model used by the mapped statement, for example:

  1 <  IDcachemodel= "Product-cache" >
  2= # value#
  3</statement>

  Read-only VS readable read-write

  The framework supports both read-only and read-write caching. Read-only caching is shared by all users and therefore performs better. However, read-only cached data should not be modified. Instead, to update the data, you must read the data from the database (or read-write cache). Therefore, if you want to read the data and modify it, you need a read-write cache. To use a read-only cache, set readonly= "true" in Cachemodel. To use a read-write cache, set readonly= "false". The default is read-only caching (true).

  Serializable writable Cache

  As you know, only the cache that is valid for the current Session has a limited effect on overall application performance. Serializable read-write caching can improve the performance of the overall application, not just each Session. This cache returns a different instance (replica) of the cache object for each Session. So each Session can safely modify the returned object. The difference is that you typically want to get the same object from the cache, but in this case you get a different object. Also, each buffered object in the Serializable cache must be Serializable. This means that both the Serializable cache and lazy loading cannot be used at the same time because the deferred loading agent is not Serializable. To know how to combine Serializable caching, lazy loading, and federated queries, the best way to do this is to try it. To use the Serializable cache, set readonly= "false" and serialize= "true". By default, the cache is read-only and does not use the Serializable cache. Read-only caching does not require Serializable.

  Cache type

  The cache Model uses plug-in methods to support different caching algorithms. Its implementation is specified in Cachemodel with the type attribute (as shown above). The specified implementation class must implement the Cachecontroller interface, or one of the 4 aliases below. Other configuration parameters implemented by the Cache Model are set by the property element of the Cachemodel. Currently, the following 4 implementations are included:

  * "MEMORY" (Com.ibatis.db.sqlmap.cache.memory.MemoryCacheController)

  The MEMORY cache implementation uses the reference type to manage the behavior of the cache. The garbage collector can determine whether to reclaim data in the cache based on the reference type. Memory implementations are suitable for applications that do not have a unified object reuse pattern, or for applications that are not under-used.

  MEMORY implementations can be configured like this:

  1 <CachemodelID= "Product-cache"type= "MEMORY">
  2 <Flushintervalhours= "+"/>
  3 <FlushonexecuteStatement= "Insertproduct"/>
  4 <FlushonexecuteStatement= "UpdateProduct"/>
  5 <FlushonexecuteStatement= "Deleteproduct"/>
  6 < Propertyname= "Reference-type"value= "WEAK"/>
  7 </Cachemodel>

  The MEMORY cache implementation recognizes only one <property> element. The value of this attribute named "Reference-type" must be one of the three Strong,soft and WEAK. These three values correspond to the different memory reference types of the JVM, respectively.

  The table below describes the different reference types in the MEMORY implementation. For a better understanding of the reference type, refer to Java.lang.ref in the JDK documentation for more information on "reachability".

  WEAK (default)	In most cases, the WEAK type is the best choice. If you do not specify a type, the default class Type is WEAK. It can greatly improve the performance of common queries. However, for query result data that is not currently being used, it is cleared to free memory for allocating other objects.
  SOFT	When the query results object data is not being used, and the memory is required to allocate other objects , the SOFT type will reduce the likelihood of running out of memory. However, this is not the most intrusive type of reference, and the resulting data may still be erased.
  Strong	The strong type ensures that the query result data remains in memory unless the Cache is refreshed (for example, to the time of the refresh or the operation that performed the update data). For the following scenario, this is the ideal choice: 1) Result content data is very small, 2) completely static data, and 3) frequently used data. The advantage is that this kind of query performance is very good. The disadvantage is that if additional objects need to be allocated, memory cannot be freed (possibly more important data objects).

  * "LRU" (Com.ibatis.db.sqlmap.cache.lru.LruCacheController)

  The LRU Cache implementation uses the "least recently used" principle to determine how objects are purged from the cache. When the cache overflows, the least recently used objects are purged from the cache. With this approach, if a particular object is always used, it will remain in the Cache and be cleared with minimal likelihood. LRU Cache is a good choice for situations where certain users often use certain objects for a longer period of time (for example, paging through paginatedlist and common query keyword results sets).

  The LRU Cache implementation can be configured like this:

  1 <CachemodelID= "Product-cache"type= "LRU">
  2 <Flushintervalhours= "+"/>
  3 <FlushonexecuteStatement= "Insertproduct"/>
  4 <FlushonexecuteStatement= "UpdateProduct"/>
  5 <FlushonexecuteStatement= "Deleteproduct"/>
  6 < Propertyname= "Size"value= "+"/>
  7 </Cachemodel>

  The LRU Cache implementation recognizes only one property element. The attribute value named "Cache-size" must be an integer representing the maximum number of objects that are saved in the cache at the same time. It is worth noting that the object here can be arbitrary, from a single String object to a Java Bean's ArrayList object. Therefore, do not Cache too many objects to avoid running out of memory.

  * "FIFO" (Com.ibatis.db.sqlmap.cache.fifo.FifoCacheController)

  FIFO Cache implementations use the "FIFO" principle to determine how objects are purged from the cache. When the cache overflows, the object that first enters the cache is purged from the cache. FIFO Cache is a good choice for situations in which a specific query is not likely to be used for a short time.

  The FIFO Cache can be configured like this:

  1 <CachemodelID= "Product-cache"type= "FIFO">
  2 <Flushintervalhours= "+"/>
  3 <FlushonexecuteStatement= "Insertproduct"/>
  4 <FlushonexecuteStatement= "UpdateProduct"/>
  5 <FlushonexecuteStatement= "Deleteproduct"/>
  6 < Propertyname= "Size"value= "+"/>
  7 </Cachemodel>

  The FIFO Cache implementation recognizes only one property element. The attribute value named "Cache-size" must be an integer representing the maximum number of objects that are saved in the cache at the same time. It is worth noting that the object here can be arbitrary, from a single String object to a Java Bean's ArrayList object. Therefore, do not Cache too many objects to avoid running out of memory.

  * "Oscache" (Com.ibatis.db.sqlmap.cache.oscache.OSCacheController)

  The Oscache cache implementation is a Plugin of the OSCache2.0 cache engine. It is highly configurable, distributed, and highly flexible.

  The Oscache implementation can be configured like this:

  1 <CachemodelID= "Product-cache"type= "Oscache">
  2 <Flushintervalhours= "+"/>
  3 <FlushonexecuteStatement= "Insertproduct"/>
  4 <FlushonexecuteStatement= "UpdateProduct"/>
  5 <FlushonexecuteStatement= "Deleteproduct"/>
  6 </Cachemodel>

  The Oscache implementation does not use the property element, but is configured with a standard oscache.properties file in the root path of the classpath. In the Oscache.properties file, you can configure the cache's algorithm (similar to the algorithm discussed above), the size of the cache, the persistence method (memory, file, and so on), and the cluster method.

Ibatis Learning Summary 4--sql map XML Map file extension