Mybatis3 API的范围和生命周期
2012-12-19 10:56
176 查看
范围和生命周期
理解我们目前已经讨论过的不同范围和生命周期类是很重要的。不正确的使用它们会导
致严重的并发问题。
SqlSessionFactoryBuilder
这个类可以被实例化,使用和丢弃。一旦你创建了SqlSessionFactory
后,这个类就不需要存在了。因此SqlSessionFactoryBuilder
实例的最佳范围是方法范围(也就是本地方法变量)。你可以重用SqlSessionFactoryBuilder
来创建多个SqlSessionFactory 实例,但是最好的方式是不需要保持它一直存在来保证所有XML
解析资源,因为还有更重要的事情要做。
SqlSessionFactory
一旦被创建,SqlSessionFactory
应该在你的应用执行期间都存在。没有理由来处理或重新创建它。使用SqlSessionFactory
的最佳实践是在应用运行期间不要重复创建多次。这样的操作将被视为是非常糟糕的。因此SqlSessionFactory
的最佳范围是应用范围。有很多方法可以做到,最简单的就是使用单例模式或者静态单例模式。然而这两种方法都不认为是最佳实践。这样的话,你可以考虑依赖注入容器,比如Google Guice
或Spring。这样的框架允许你创建支持程序来管理单例SqlSessionFactory
的生命周期。
SqlSession
每个线程都应该有它自己的SqlSession
实例。SqlSession 的实例不能被共享,也是线程
不安全的。因此最佳的范围是请求或方法范围。绝对不能将SqlSession
实例的引用放在一个类的静态字段甚至是实例字段中。也绝不能将SqlSession
实例的引用放在任何类型的管理范围中,比如Serlvet
架构中的HttpSession 。如果你现在正用任意的Web
框架,要考虑SqlSession放在一个和HTTP
请求对象相似的范围内。换句话说,基于收到的HTTP
请求,你可以打开了一个SqlSession,然后返回响应,就可以关闭它了。关闭 Session
很重要,你应该确保使用finally 块来关闭它。下面的示例就是一个确保SqlSession
关闭的基本模式: SqlSession session = sqlSessionFactory.openSession();
try {
// do work
} finally {
session.close();
}
在你的代码中一贯地使用这种模式,将会保证所有数据库资源都正确地关闭(假设你没有通过你自己的连接关闭,这会给MyBatis
造成一种迹象表明你要自己管理连接资源)。
Mapper
实例
映射器是你创建绑定映射语句的接口。映射器接口的实例可以从SqlSession
中获得。那么从技术上来说,当被请求时,任意映射器实例的最宽范围和 SqlSession
是相同的。然而,映射器实例的最佳范围是方法范围。也就是说,它们应该在使用它们的方法中被请求,然后就抛弃掉。它们不需要明确地关闭,那么在请求对象中保留它们也就不是什么问题了,这和SqlSession
相似。你也许会发现,在这个水平上管理太多的资源的话会失控。保持简单,将映射器放在方法范围内。下面的示例就展示了这个实践:
SqlSession session = sqlSessionFactory.openSession();
try {
BlogMapper mapper = session.getMapper(BlogMapper.class);
// do work
} finally {
session.close();
}
理解我们目前已经讨论过的不同范围和生命周期类是很重要的。不正确的使用它们会导
致严重的并发问题。
SqlSessionFactoryBuilder
这个类可以被实例化,使用和丢弃。一旦你创建了SqlSessionFactory
后,这个类就不需要存在了。因此SqlSessionFactoryBuilder
实例的最佳范围是方法范围(也就是本地方法变量)。你可以重用SqlSessionFactoryBuilder
来创建多个SqlSessionFactory 实例,但是最好的方式是不需要保持它一直存在来保证所有XML
解析资源,因为还有更重要的事情要做。
SqlSessionFactory
一旦被创建,SqlSessionFactory
应该在你的应用执行期间都存在。没有理由来处理或重新创建它。使用SqlSessionFactory
的最佳实践是在应用运行期间不要重复创建多次。这样的操作将被视为是非常糟糕的。因此SqlSessionFactory
的最佳范围是应用范围。有很多方法可以做到,最简单的就是使用单例模式或者静态单例模式。然而这两种方法都不认为是最佳实践。这样的话,你可以考虑依赖注入容器,比如Google Guice
或Spring。这样的框架允许你创建支持程序来管理单例SqlSessionFactory
的生命周期。
SqlSession
每个线程都应该有它自己的SqlSession
实例。SqlSession 的实例不能被共享,也是线程
不安全的。因此最佳的范围是请求或方法范围。绝对不能将SqlSession
实例的引用放在一个类的静态字段甚至是实例字段中。也绝不能将SqlSession
实例的引用放在任何类型的管理范围中,比如Serlvet
架构中的HttpSession 。如果你现在正用任意的Web
框架,要考虑SqlSession放在一个和HTTP
请求对象相似的范围内。换句话说,基于收到的HTTP
请求,你可以打开了一个SqlSession,然后返回响应,就可以关闭它了。关闭 Session
很重要,你应该确保使用finally 块来关闭它。下面的示例就是一个确保SqlSession
关闭的基本模式: SqlSession session = sqlSessionFactory.openSession();
try {
// do work
} finally {
session.close();
}
在你的代码中一贯地使用这种模式,将会保证所有数据库资源都正确地关闭(假设你没有通过你自己的连接关闭,这会给MyBatis
造成一种迹象表明你要自己管理连接资源)。
Mapper
实例
映射器是你创建绑定映射语句的接口。映射器接口的实例可以从SqlSession
中获得。那么从技术上来说,当被请求时,任意映射器实例的最宽范围和 SqlSession
是相同的。然而,映射器实例的最佳范围是方法范围。也就是说,它们应该在使用它们的方法中被请求,然后就抛弃掉。它们不需要明确地关闭,那么在请求对象中保留它们也就不是什么问题了,这和SqlSession
相似。你也许会发现,在这个水平上管理太多的资源的话会失控。保持简单,将映射器放在方法范围内。下面的示例就展示了这个实践:
SqlSession session = sqlSessionFactory.openSession();
try {
BlogMapper mapper = session.getMapper(BlogMapper.class);
// do work
} finally {
session.close();
}
相关文章推荐
- mybatis 各个重要组件的范围和生命周期
- MyBatis对象的范围和生命周期
- mybatis-范围和生命周期
- MyBatis中主要类的生命周期和应用范围
- MyBatis中对象的范围和生命周期
- MyBatis之八:需要说明的几个java api的生命周期以及封装
- MyBatis范围和生命周期
- 力所能及之Mybatis 范围和生命周期
- ArcGIS api for javascript——加入地图并显示当前地图范围
- Java学习笔记 Java调用Win32 API控制鼠标活动范围
- React生命周期以及主要的API介绍
- Mybatis笔记三:MyBatis的API文档
- Java Web笔记 – Servlet技术介绍 生命周期 核心API 类方法调用顺序
- Spring——自定义属性编辑器+Bean的生存范围+Bean的生命周期
- [翻译] Autofac 控制范围和生命周期
- MyBatis之作用域和生命周期(二)
- 三、范围和生命周期
- 4.Maven概念模型,maven的生命周期,Maven坐标,依赖管理(依赖范围,依赖声明),仓库管理,私服概念
- Mybatis--Java API
- Mybatis中sqlsessionfactory和sqlsesstion的作用范围