xml中mybatis解析mapper的方式
- url
- resource
- class
- pakeage
<mappers>
<mapper resource="org/mybatis/example/BlogMapper.xml"/>
<mapper class="com.zdd.mybatis.TestMapper"></mapper>
<mapper url="http://localhost/zdd/example/BlogMapper.xml"></mapper>
<package name="com.zdd.mybatis"/>
</mappers>
mybatis和spring mybatis日志的解析
mybatis单独使用时加上log4j是可以使用日志的
但是如果mybatis和spring5整合的话mybatis是无法直接使用log4j日志的
下面是mybatis日志工厂对象初始化时的静态化代码块
因为spring5内置的jcl,所以还不能到达第四行代码,在第二行代码就会实例化日志对象,就会使用spring5内置的jcl,因为spring5的jcl是经过改造过的,是无法直接使用log4j的,所以使用的还是jul
因为jul的日志级别是info up,但是能够打印数据库日志的是info down级别的
下面时打印日志时会判断日志级别,因为jul的日志级别不够所以是打印不出来的,而且想要修改jul的日志级别是很困难的
其实如果使用spring4的话这个问题就不会出现,因为spring4是使用的是原生的jcl
spring mybatis一级缓存失效
mybatis和spring整合后以及缓存会失效
这是因为spring会将mybatis的mapper对象放入容器,并且真正的对象其实是一个factroybean对象,只不过返回的是mapper对象的代理对象
而且真正执行mapper中的方法时,使用的是一个sqlsession的代理对象去执行的数据库方法,这个对象在执行完mapper中方法的逻辑后会将session关闭
在通过debug模式下进入查询语句时会发现进入的是一个代理对象,这个代理对象正是在容器中对应的一个factroybean对象返回的真正对象
底层依然是原生的mybatis的数据库查询
接着会到一个SqlSessionTemplate的包装类,执行其中的代理对象的查询方法
在查询过后会将session关闭,这也是为什么一级缓存失效的直接原因
原生mybatis的调用链和spring mybatis的调用链的区别
mybatis–→sqlSession–→defaultSqlSession–→defaultSqlSession.selectList–→sql
spring mybatis–→sqlSession–→sqlSessionTemplate–→sqlSessionTemplate.selectList–→sqlSessionPorxy.select
这里至于为什么要关闭session,是因为sqlSession是已经被spring管理的,并没有暴露给使用者,所以我们是关不了的,这样spring就帮我们管理了,就关闭了。
而在原生的mybatis中我们是很容易拿到sqlSession,所以我们可以手动关闭session。
至于为什么spring不把sqlSession暴露给使用者,也许是太过麻烦,也许是一级缓存太过鸡肋。
mapper对象实例化过程
实现这个接口initializingBean可以在bean初始化的时候执行它实现的方法afterPropertiesSet
而mybatis正是通过这个方法将mapper初始化,把mapper的一些信息(注解等)放入sqlSession
而且这个方法是在@PostConstruct方法之后执行的