事务管理最佳实践多余的话之一
----“每次请求，一次数据库连接，一次事务”是不是金科玉律？
前言
《事务管理最佳实践多余的话之一》，不知道会不会还有之二、之三。
“每次请求，一次数据库连接，一次事务”是不是金科玉律？
在《事务管理最佳实践全面解析》一文中，我曾经说过，最佳的事务管理模式，是“每次请求，一次数据库连接，一次事务”。这个原则，是不是必须严格执行的金科玉律呢？不是！
“每次请求，一次数据库连接，一次事务”，这只是一个大体的原则，表示我们的数据库连接和事务在一个请求的范围内，应该尽可能得长。并不是一定要你遵循这个原则。所有的原则、理论，只是指导你工作的思想武器，决不是约束你的条条框框。面对具体情况，你可以灵活处理。
完全可以这样做：“每次请求，多次数据库连接，多次事务”。
请看下面这个例子：
一、这是SpringMVC的一个控制器的方法
前台页面上是一个多选框，选中多个要删除的工作流。传递的参数，是各个工作流的名字。
这里，在循环中调用服务类的Transaction方法:uninstallJbpmProcessDefinitionsTransaction(names[i])
卸载Jbpm的业务程序定义，及其全部实例、任务。
/**
*删除该页选中的业务程序定义
*@paramrequest
*@paramresponse
*@return
*@throwsException
*/
public ModelAndView uninstall(HttpServletRequest request,HttpServletResponse response,ProcessDefinitionNames command) throws Exception{
/**
*1,选中的工作流名字。
*/
String[] names=command.getNames();
for(int i=0;i<names.length;i++){
this.getUninstallProcessDefinition().uninstallJbpmProcessDefinitionsTransaction(names[i]);
}
returnnew ModelAndView(UrlMap.map("manage.uninstallProcessDefinition.uninstall"));
}
二、这是服务类的相关方法
（一）这是服务类的Transaction方法。创建和关闭了Hibernate的Session，同时也处理了事务。
/* (non-Javadoc)
* @see com.withub.common.util.IUninstallProcessDefinition#uninstallJbpmProcessDefinitionsTransaction(java.lang.String)
*/
publicvoid uninstallJbpmProcessDefinitionsTransaction(String name){
JbpmContext jbpmContext = JbpmConfiguration.getInstance().createJbpmContext();
try {
this.uninstallJbpmProcessDefinitionsDao(name);
}finally{
jbpmContext.close();
}
}
（二）这是具体使用Hibernate的数据访问方法，执行卸载业务程序定义的方法。
控制器层不能直接调用它，因为它没有提供处理“得到和关闭数据库连接，管理事务”任务的代码。
/**
*
*@paramname
*/
privatevoid uninstallJbpmProcessDefinitionsDao(String name){
JbpmContext jbpmContext = JbpmConfiguration.getInstance().getCurrentJbpmContext();
GraphSession graphSession=jbpmContext.getGraphSession();
List processDefinitions=graphSession.findAllProcessDefinitionVersions(name);
if(processDefinitions!=null){
Iterator iterator=processDefinitions.iterator();
while(iterator.hasNext()){
graphSession.deleteProcessDefinition((ProcessDefinition)iterator.next());
}
}
log.info("卸载工作流："+name);
}
例子解析
上面这个例子中，控制器中，每一次循环，都重复执行了“得到和关闭数据库连接，管理事务”的代码。因此，违背了“每次请求，一次数据库连接，一次事务”的原则。
依照这个原则，我们需要在服务类中重新写一个Transaction方法，把所有循环放在try块中。只使用一个数据库连接和事务。
这样做，当然可以。但是，上面的代码也没有什么问题。如果在控制器方法执行过程中，发生异常，那么可能有的Jbpm工作流定义（我叫它们为“业务程序定义”）被卸载了，有的没有被卸载。但是，这不会破坏数据库中数据的完整性和正确性。
上面这段代码，唯一的问题是，数据库连接的获取和关闭太频繁。但是，根据这个控制器方法的业务逻辑，我们知道，这个循环并不会太大。因为，要卸载的业务程序定义不可能很多。而且，这个功能的前台页面是分页的，因此，不会一次卸载太多的业务程序定义。所以，这个问题并不是很严重。
既然如此，基于实用主义的原则，我不打算修改上面的代码。这样，我就减少了编写一个Service类的Transaction方法的麻烦。现在使用的这个Transaction方法是原来就开发好的。（为了一个命令行卸载工具开发的）
结语
这篇“多余的话”，就是希望读者不要走极端。在理想主义和现实情况之间，我们应该用现实主义的方法来看待问题，解决问题。“不管白猫黑猫，抓住老鼠就是好猫”!当然，在现实生活中，我还是希望你能够想得更深一点，永远保持“精益求精”的精神，多问问为什么，怎样才能做得更好。这样，才能有助于你进一步提高。
我记得《代码大全》的作者Steve McConnell，曾经说过（我不记得原话了，大概就是下面我说的这个意思）：一个程序员的能够达到的成就，从他从业的第一年就可以看出来。一个程序员，在从业一年之后，应该已经可以胜任大部分工作。如果他不再追求更好的编码，只是得过且过，吃老本，那么这个程序员不管从业多少年，永远只是菜鸟级的。如果一个程序员，在从业两年之后，依然保持着旺盛的求知欲，那么他的前途将是无可限量的！
希望你是后者，当然，如果你想转作管理，那么选择作前者，你的“钱途”更加光明！
