??????????????????????????????????????????
事務(wù)管理最佳實(shí)踐多余的話之一????????????????????????????????????????? ? ----“每次請(qǐng)求，一次數(shù)據(jù)庫連接，一次事務(wù)”是不是金科玉律？
前言
《事務(wù)管理最佳實(shí)踐多余的話之一》，不知道會(huì)不會(huì)還有之二、之三。
?
“每次請(qǐng)求，一次數(shù)據(jù)庫連接，一次事務(wù)”是不是金科玉律？
“每次請(qǐng)求，一次數(shù)據(jù)庫連接，一次事務(wù)”，這只是一個(gè)大體的原則，表示我們的數(shù)據(jù)庫連接和事務(wù)在一個(gè)請(qǐng)求的范圍內(nèi)，應(yīng)該盡可能得長(zhǎng)。并不是一定要你遵循這個(gè)原則。所有的原則、理論，只是指導(dǎo)你工作的思想武器，決不是約束你的條條框框。面對(duì)具體情況，你可以靈活處理。
完全可以這樣做：“每次請(qǐng)求，多次數(shù)據(jù)庫連接，多次事務(wù)”。
請(qǐng)看下面這個(gè)例子：
?
一、這是SpringMVC的一個(gè)控制器的方法
前臺(tái)頁面上是一個(gè)多選框，選中多個(gè)要?jiǎng)h除的工作流。傳遞的參數(shù)，是各個(gè)工作流的名字。
這里，在循環(huán)中調(diào)用服務(wù)類的Transaction方法:uninstallJbpmProcessDefinitionsTransaction(names[i])
卸載Jbpm的業(yè)務(wù)程序定義，及其全部實(shí)例、任務(wù)。
/**
?????*刪除該頁選中的業(yè)務(wù)程序定義
?????*@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"));
????}
?
二、這是服務(wù)類的相關(guān)方法
（一）這是服務(wù)類的Transaction方法。創(chuàng)建和關(guān)閉了Hibernate的Session，同時(shí)也處理了事務(wù)。
/*?(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的數(shù)據(jù)訪問方法，執(zhí)行卸載業(yè)務(wù)程序定義的方法。
控制器層不能直接調(diào)用它，因?yàn)樗鼪]有提供處理“得到和關(guān)閉數(shù)據(jù)庫連接，管理事務(wù)”任務(wù)的代碼。
/**
?????*
?????*@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);
????}
例子解析
上面這個(gè)例子中，控制器中，每一次循環(huán)，都重復(fù)執(zhí)行了“得到和關(guān)閉數(shù)據(jù)庫連接，管理事務(wù)”的代碼。因此，違背了“每次請(qǐng)求，一次數(shù)據(jù)庫連接，一次事務(wù)”的原則。
依照這個(gè)原則，我們需要在服務(wù)類中重新寫一個(gè)Transaction方法，把所有循環(huán)放在try塊中。只使用一個(gè)數(shù)據(jù)庫連接和事務(wù)。
這樣做，當(dāng)然可以。但是，上面的代碼也沒有什么問題。如果在控制器方法執(zhí)行過程中，發(fā)生異常，那么可能有的Jbpm工作流定義（我叫它們?yōu)椤皹I(yè)務(wù)程序定義”）被卸載了，有的沒有被卸載。但是，這不會(huì)破壞數(shù)據(jù)庫中數(shù)據(jù)的完整性和正確性。
上面這段代碼，唯一的問題是，數(shù)據(jù)庫連接的獲取和關(guān)閉太頻繁。但是，根據(jù)這個(gè)控制器方法的業(yè)務(wù)邏輯，我們知道，這個(gè)循環(huán)并不會(huì)太大。因?yàn)椋遁d的業(yè)務(wù)程序定義不可能很多。而且，這個(gè)功能的前臺(tái)頁面是分頁的，因此，不會(huì)一次卸載太多的業(yè)務(wù)程序定義。所以，這個(gè)問題并不是很嚴(yán)重。
既然如此，基于實(shí)用主義的原則，我不打算修改上面的代碼。這樣，我就減少了編寫一個(gè)Service類的Transaction方法的麻煩。現(xiàn)在使用的這個(gè)Transaction方法是原來就開發(fā)好的。（為了一個(gè)命令行卸載工具開發(fā)的）
?
結(jié)語
這篇“多余的話”，就是希望讀者不要走極端。在理想主義和現(xiàn)實(shí)情況之間，我們應(yīng)該用現(xiàn)實(shí)主義的方法來看待問題，解決問題。“不管白貓黑貓，抓住老鼠就是好貓”!當(dāng)然，在現(xiàn)實(shí)生活中，我還是希望你能夠想得更深一點(diǎn)，永遠(yuǎn)保持“精益求精”的精神，多問問為什么，怎樣才能做得更好。這樣，才能有助于你進(jìn)一步提高。
我記得《代碼大全》的作者Steve McConnell，曾經(jīng)說過（我不記得原話了，大概就是下面我說的這個(gè)意思）：一個(gè)程序員的能夠達(dá)到的成就，從他從業(yè)的第一年就可以看出來。一個(gè)程序員，在從業(yè)一年之后，應(yīng)該已經(jīng)可以勝任大部分工作。如果他不再追求更好的編碼，只是得過且過，吃老本，那么這個(gè)程序員不管從業(yè)多少年，永遠(yuǎn)只是菜鳥級(jí)的。如果一個(gè)程序員，在從業(yè)兩年之后，依然保持著旺盛的求知欲，那么他的前途將是無可限量的！
希望你是后者，當(dāng)然，如果你想轉(zhuǎn)作管理，那么選擇作前者，你的“錢途”更加光明！
?
?
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1417657