1 背景

这是一个安静祥和没有bug的下午。
作为一只菜鸡,时刻巩固一下基础还是很有必要的,如此的大好时机,就让我来学习学习mybatis如何使用。

这可和我看到的不一样啊,让我来看看项目里怎么写的。

我们项目中的Dao都继承于BaseDao,而BaseDao继承于SqlSessionDaoSupport,每次执行sql的时候都是直接将这个sqlSession返回,然后执行sql,这难道不是一个实例变量嘛?这和你说的可不一样诶。于是带着这样的疑问,我开始了探索。

2 探索之旅

1)我们都知道,在使用mybatis时,sqlSession都来自于sqlSessionFactory,而sqlSessionFactory可以通过sqlSessionFactoryBuilder创建,也可以通过spring初始化,而项目中很显然采取了后一种方式。

2)那么我们已经得到了sqlSessionFactory,应该如何去进一步探索sqlSession的来源呢,我想到可以通过项目中已经实现的dao进行探索。我们随便选取一个dao为例。

它继承了BaseDao。

而BaseDao又继承了SqlSessionDaoSupport,在BaseDao中调用了getSqlSession方法,实际上也就是SqlSessionDaoSupport的getSqlSession方法。

而SqlSessionDaoSupport的getSqlSession方法是直接将自己的成员变量返回去的,截至目前为止,和我的怀疑点是相符合的,即目前的写法和mybatis官网的说明是冲突的。

3)反复阅读SqlSessionDaoSupport这个类后,终于被我发现了线索,细心的小伙伴应该也早已发现了,就在上图之中的注释中,“用户应该使用这个方法来获得一个SqlSession来执行sql语句,这个SqlSession被spring管理,用户不应该提交、回滚或关闭它。因为这些已经被自动执行了。”

同时,这个方法会返回一个线程安全的SqlSession。

那么这个SqlSession是从何而来的呢,从上图可以看出,它有两种赋值方式,一种是给他传一个SqlSessionFactory,生成SqlSessionTemplate,SqlSessionTemplate即为sqlSession。另一种是直接给他传一个SqlSessionTemplate作为SqlSession。根据本类的注释,如果SqlSessionFactory和SqlSessionTemplate都被定义了,那么SqlSessionFactory的方式会失效。至此,我的上述疑问已经解决了,也就是说这个SqlSession并不是一个mybatis初始的SqlSession,而是spring实现的SqlSessionTemplate。

4)但是,我又诞生了新的疑问,SqlSessionTemplate是怎么完成线程安全的呢?

于是我进入了SqlSessionTemplate的方法执行,发现实际执行语句的都是这个代理类sqlSessionProxy。

而代理工作内容就在SqlSessionInterceptor这个handler里。

进入其中,我们终于发现了它的获取和关闭操作。

也就是说,每次执行,代理都会调用sessionFactory的openSession方法获得一个新的session。

3 总结

终于的终于,mybatis,spring,项目以及我的疑问得到了统一,真是一个宁静祥和而又没有bug的下午呀。


作者:马跃