Mybatis配置文件之配置元素解析

Mybatis配置文件之配置元素解析

1. 概述

首先我们看下在之前文章中的关于mybatis-config.xml文件中的environments元素的配置：

    <environments default="development">
        <environment id="development">
            
            <transactionManager type="JDBC"/>
            
            <dataSource type="POOLED">
                <property name="driver" value="${driver}"/>
                <property name="url" value="${url}"/>
                <property name="username" value="${username}"/>
                <property name="password" value="${password}"/>
            dataSource>
        environment>
    environments>

从上面看，我们知道下面可以配置多个元素节点，而每个节点我们可以配置两个东西，一个是事务管理器配置，另一个是数据源配置。我们分析下上面的配置：
（1）environments上的default属性表示在默认的情况下我们将启用的数据源
（2）environment元素表示一个数据源配置的开始，属性id用来标识一个数据源的，方便在mybatis中使用
（3）transactionManager是用来配置事物的，其type属性有三个值：
- JDBC 采用JDBC管理事务，在独立编码中我们经常使用
- MANAGED 采用容器方式管理事务，在JNDI数据源中使用
- 自定义 由使用者自定义数据库事务管理方法，适用于某些特殊场景
- 在transactionManager中还可以配置property子元素，来设置事务的一些属性，如autoCommit=false

            <transactionManager type="JDBC">
                <property name="autoCommit" value="false"/>
            transactionManager>

（4）dataSource 配置一个数据源链接等相关信息，type属性是用来配置数据库连接方式的，mybatis也提供了一下几种方式：
- UNPOOLED 非连接池数据库
- POOLED 连接池数据库
- JNDI JNDI数据源
- 自定义数据源
在dataSource中的property子元素就是用来定义数据源各种参数的。

2. 源码分析

2.1 解析指定的environment元素

我们回到mybatis的配置文件的解析的方法XMLConfigBuilder.parseConfiguration中，如下图所示：

environmentsElement(root.evalNode(“environments”))来进行environments元素解析的，进入方法内部：

  private void environmentsElement(XNode context) throws Exception {
    if (context != null) {
      if (environment == null) {
        environment = context.getStringAttribute("default");
      }
      for (XNode child : context.getChildren()) {
        String id = child.getStringAttribute("id");
        if (isSpecifiedEnvironment(id)) {
          TransactionFactory txFactory = transactionManagerElement(child.evalNode("transactionManager"));
          DataSourceFactory dsFactory = dataSourceElement(child.evalNode("dataSource"));
          DataSource dataSource = dsFactory.getDataSource();
          Environment.Builder environmentBuilder = new Environment.Builder(id)
              .transactionFactory(txFactory)
              .dataSource(dataSource);
          configuration.setEnvironment(environmentBuilder.build());
        }
      }
    }
  }

从代码看，就是首先获取标签元素的default属性，这个属性作用就是指定当前情况下使用哪个数据库配置，也就是使用哪个节点的配置，default的值就是配置的标签元素的id值。
正如上面代码中isSpecifiedEnvironment(id)方法一样，在遍历所有的时候一次判断相应的id是否是default设置的值，如果是，则使用当前元素进行数据库连接的初始化。继续看下isSpecifiedEnvironment方法，如下：

  private boolean isSpecifiedEnvironment(String id) {
    if (environment == null) {
      throw new BuilderException("No environment specified.");
    } else if (id == null) {
      throw new BuilderException("Environment requires an id attribute.");
    } else if (environment.equals(id)) {
      return true;
    }
    return false;
  }

2.2 设置事务

在上面找到指定的environment后就要进行事务的设置了，配置事务是在方法transactionManagerElement(child.evalNode(“transactionManager”))来实现的，进入方法内部：

  private TransactionFactory transactionManagerElement(XNode context) throws Exception {
    if (context != null) {
      String type = context.getStringAttribute("type");
      Properties props = context.getChildrenAsProperties();
      TransactionFactory factory = (TransactionFactory) resolveClass(type).newInstance();
      factory.setProperties(props);
      return factory;
    }
    throw new BuilderException("Environment declaration requires a TransactionFactory.");
  }

我们可以看到，这里其实是根据这个元素的type属性来找相应的事务管理器的。
在Mybatis里面支持两种配置：JDBC和MANAGED。这里根据type的设置值来返回相应的事务管理器。我们看下，在Mybatis的Configuration类中，已经将这两种配置及对应的事务管理器做了某种关联，如下所示：

public Configuration() {  
    typeAliasRegistry.registerAlias("JDBC", JdbcTransactionFactory.class);  
    typeAliasRegistry.registerAlias("MANAGED", ManagedTransactionFactory.class);  
    ....
    }

这两种事务管理器的区别：
JDBC：这个配置就是直接使用了 JDBC 的提交和回滚设置，它依赖于从数据源得到的连接来管理事务作用域。
MANAGED：这个配置几乎没做什么。它从来不提交或回滚一个连接，而是让容器来管理事务的整个生命周期（比如 JEE 应用服务器的上下文）。 默认情况下它会关闭连接，然而一些容器并不希望这样，因此需要将 closeConnection 属性设置为 false 来阻止它默认的关闭行为

2.3. 设置数据源

接下来我们看下数据源的设置，使用的是：dataSourceElement(child.evalNode(“dataSource”));，进入到方法内部：

  private DataSourceFactory dataSourceElement(XNode context) throws Exception {
    if (context != null) {
      String type = context.getStringAttribute("type");
      Properties props = context.getChildrenAsProperties();
      DataSourceFactory factory = (DataSourceFactory) resolveClass(type).newInstance();
      factory.setProperties(props);
      return factory;
    }
    throw new BuilderException("Environment declaration requires a DataSourceFactory.");
  }

通过方法可以看到其实现与设置事务基本相同，Mybatis支持三种内建的数据源类型，分别是UNPOOLED、POOLED和JNDI，即我们在配置元素的type属性时，我们可以直接支持设置这三个值。
下面分别对这三种类型做一个简单的说明：
（1）UNPOOLED
这个数据源的实现只是每次被请求时打开和关闭连接。虽然一点慢，它对在及时可用连接方面没有性能要求的简单应用程序是一个很好的选择。 不同的数据库在这方面表现也是不一样的，所以对某些数据库来说使用连接池并不重要，这个配置也是理想的。
UNPOOLED 类型的数据源仅仅需要配置以下 5 种属性：
driver ： 这是 JDBC 驱动的 Java 类的完全限定名（并不是JDBC驱动中可能包含的数据源类）。
url ：这是数据库的 JDBC URL 地址。
username ： 登录数据库的用户名。
password ：登录数据库的密码。
defaultTransactionIsolationLevel ： 默认的连接事务隔离级别。
作为可选项，你也可以传递属性给数据库驱动。要这样做，属性的前缀为“driver.”，例如：
driver.encoding=UTF8
这将通过DriverManager.getConnection(url,driverProperties)方法传递值为 UTF8 的 encoding 属性给数据库驱动。
（2）POOLED
这种数据源的实现利用“池”的概念将 JDBC 连接对象组织起来，避免了创建新的连接实例时所必需的初始化和认证时间。 这是一种使得并发 Web 应用快速响应请求的流行处理方式。
除了上述提到 UNPOOLED 下的属性外，会有更多属性用来配置 POOLED 的数据源：
poolMaximumActiveConnections ： 在任意时间可以存在的活动（也就是正在使用）连接数量，默认值：10
poolMaximumIdleConnections ：任意时间可能存在的空闲连接数。
poolMaximumCheckoutTime ：在被强制返回之前，池中连接被检出（checked out）时间，默认值：20000 毫秒（即 20 秒）
poolTimeToWait ：这是一个底层设置，如果获取连接花费的相当长的时间，它会给连接池打印状态日志并重新尝试获取一个连接（避免在误配置的情况下一直安静的失败），默认值：20000 毫秒（即 20 秒）。
poolPingQuery ： 发送到数据库的侦测查询，用来检验连接是否处在正常工作秩序中并准备接受请求。默认是“NO PING QUERY SET”，这会导致多数数据库驱动失败时带有一个恰当的错误消息。
poolPingEnabled ： 是否启用侦测查询。若开启，也必须使用一个可执行的 SQL 语句设置 poolPingQuery 属性（最好是一个非常快的 SQL），默认值：false。poolPingConnectionsNotUsedFor ： 配置 poolPingQuery 的使用频度。这可以被设置成匹配具体的数据库连接超时时间，来避免不必要的侦测，默认值：0（即所有连接每一时刻都被侦测 — 当然仅当 poolPingEnabled 为 true 时适用）。
（3）JNDI
这个数据源的实现是为了能在如 EJB 或应用服务器这类容器中使用，容器可以集中或在外部配置数据源，然后放置一个 JNDI 上下文的引用。这种数据源配置只需要两个属性：
initial_context ： 这个属性用来在 InitialContext 中寻找上下文（即，initialContext.lookup(initial_context)）。这是个可选属性，如果忽略，那么 data_source 属性将会直接从 InitialContext 中寻找。
data_source ： 这是引用数据源实例位置的上下文的路径。提供了 initial_context 配置时会在其返回的上下文中进行查找，没有提供时则直接在 InitialContext 中查找。
和其他数据源配置类似，可以通过添加前缀“env.”直接把属性传递给初始上下文。比如：
env.encoding=UTF8
这就会在初始上下文（InitialContext）实例化时往它的构造方法传递值为 UTF8 的 encoding 属性。