積累,創(chuàng)造,分享!

問題現(xiàn)象：在做web應用時會碰到這種情況，某些地方無法通過web當中的ApplicationContext來獲得springIOC容器提供的bean，比如提供給外界的webservice接口，這個時候就需要手工通過ClassPathXmlApplicationContext等方式來獲取ApplicationContext，代碼如下：
ApplicationContext context = new ClassPathXmlApplicationContext(
    "applicationContext-*.xml");
IXXXService xxxservice = (IXXXService ) context
    .getBean("xxxservice ");
這是一段很典型的加載。
然而，正是這種看似到處都是的加載卻為后面的BUG埋下伏筆。
xxxservice是具體的業(yè)務類，它向下與DAO依賴并控制著事務，這里代表了一個經(jīng)典而且簡單的service，具體配置略去，值得一提的是scope，這里沒有指定，默認的是單例。
一切都是那么順利，像這樣的service代碼寫的應該不下幾百個，可能諸位寫的更多，過程依然很陶醉，修改完畢。測試，再測試。什么？ORA-12519錯誤！見鬼，我打造的這套號稱簡易快速的SSH2框架已經(jīng)在多個項目好評無數(shù)久經(jīng)考驗了，寫了不下幾百次的service居然報ORA-12519錯誤。
迅速打開PLSQL，檢查數(shù)據(jù)庫session，Select Count(1) From v$session t Where t.SCHEMANAME='XXX';
隨著service的執(zhí)行，session數(shù)在增加，沒有減少的意思。是的，當時就是這樣。

解決思路：這種錯誤出現(xiàn)在久經(jīng)考驗的框架當中，我心里是相當不安的，居然會有這種低級趣味的錯誤。整理思路開始分析：這段代碼唯一與以前不同的地方就是，我們在web應用中，是通過容器加載提供bean的，只有容器啟動的時候才會加載xml。那么重點就應該是關注XML的加載方式了。
在這里我們用的是ApplicationContext接口。注意看spring文檔3.5.1.2.2 在非web應用中優(yōu)雅地關閉springioc容器。它這里用到的是AbstractApplicationContext，在取得bean后，再執(zhí)行一個context.registerShutdownHook();
這里實驗一把，將ApplicationContext改成AbstractApplicationContext，執(zhí)行context.close()。結(jié)果出來了，session已被正常回收，真相漸漸浮出水面。

結(jié)論：每次加載context的做法相當于每次都生成了一次新的spring容器，在默認單例的情況下，如果不及時關閉context。service所依賴的DAO當中創(chuàng)建的dataSource也一直存在（包括所有的單例情況下所生成的類)，從日志看，service事務管轄中的session確實已經(jīng)關閉，但SessionFactory還是存在的。只有在容器關閉的情況下，并指定了dataSource實例配置中的destroy-method="close"，dataSource單例才會被釋放。
spring文檔當中對生命周期也描述的很清楚。通過DisposableBean或者指定destroy-method都能很好的釋放單例對象。而prototype類型的對象需要客戶端顯式的指定釋放，釋放對象完全是客戶端控制,spring不負責釋放。
所以，要改善context的加載方式，盡量的少多次去加載，實在沒辦法的情況下，一定要記得關閉。
最后，寫代碼的隨意性，圖省事，不經(jīng)思考，是造成這種BUG的罪惡根源。

至于docbook的好處，我也不多說了，就跟吃菜一樣，嘗過了就知道到底有幾好
趁目前有空，部門內(nèi)部準備補充一下之前缺乏的技術文檔。利用這次機會，我再次收想到了docbook。
記得第一次接觸docbook的時候，還是3年前的時候了，可惜那個時候沒有堅持使用下來。
當初拋棄它的原因是多方面的，缺乏恒心是一方面，配置煩瑣也是一方面，另外還有一個很重要的原因就

是缺乏一個所見即所得的編輯器。而這次，這些煩惱徹底解決。XMLmind XML Editor!第一次發(fā)現(xiàn)它的時

候有點相見恨晚的感覺，它讓我的文檔寫的如此輕松。
不過有一點要注意，在官網(wǎng)下載的XMLmind XML Editor個人版是不支持直接將xml生成的html,pdf等格式

的。還好，目前有xsltproc，fop，openjade這些工具支持，有了這些在windows下也可以轉(zhuǎn)換的工具，生

成其他格式也不是什么難事。我目前就使用xsltproc來生成html。

附上XMLmind XML Editor的下載地址http://www.xmlmind.com/xmleditor/persoedition.html
附加上xsltproc的下載地址 http://www.zlatkovic.com/pub/libxml/
再附上docbook的地址http://www.oasis-open.org/docbook/

之前的麻煩統(tǒng)統(tǒng)消失，那么剩下的就是享受它的好處了。

不用word，文檔也可以寫的這么漂亮。docbook，看第二眼發(fā)現(xiàn)你依然還是那么好。

在目前使用的現(xiàn)有框架當中，利用spring的AOP機制來控制事務處理是目前最流行的一種控制事務的方式。

但是我們在某種使用場合的過程中，為什么有時事務處理老是不起作用呢？這里,為您道出原因之一,

首先請看一段話

Spring的事務實現(xiàn)采用基于AOP的攔截器來實現(xiàn)，如果沒有在事務配置的時候注明回滾的checked exception，那么只有在發(fā)生了unchecked exception的時候，才會進行事務回滾。

有必要先解釋一下checked exception與unchecked exception：

先看看EXCEPTION在JDK文檔當中的結(jié)構

java.lang.Object

  java.lang.Throwable

      java.lang.Exception

          java.lang.RuntimeException

而Unchecked exception: 這類異常都是RuntimeException的子類，雖然RuntimeException同樣也是Exception的子類，但是它們是特殊的。Exception是作為checked Exception 出現(xiàn)的。

所以，除了Error與RuntimeException，其他剩下的異常都是你需要關心的，而這些異常類統(tǒng)稱為Checked Exception

有了以上的基礎，看看我們框架當中的事務屬性

<property name="transactionAttributes">

                     <props>

                            <prop key="get*">PROPAGATION_REQUIRED,readOnly </prop>

                            <prop key="save*">PROPAGATION_REQUIRED </prop>

                            <prop key="delete*">PROPAGATION_REQUIRED</prop>

                            <prop key="update*">PROPAGATION_REQUIRED </prop>

                     </props>

</property>

此處，我們沒有指定任何異常，那么它目前默認處理的就是unchecked exception了，再結(jié)合我們自身每個項目的模塊，在我們的每個項目當中幾乎都定義了自己的異常，這些異常都是繼承自Exception，很不幸的是，我們繼承的Exception包括自己定義的異常，都是checked exception。

所以，在我們的事務處理機制當中，事務不管用了。

解決辦法有2個：

1，在事務屬性后面加上需要回滾的checked exception。比如<prop key="save*">PROPAGATION_REQUIRED,-XXXXException</prop>(注意那個"-",對應的是"+")

2, 不改配置文件，將需要事務回滾的異常繼承自unchecked exception類，也就是RuntimeException。

(nighthawk)

現(xiàn)在再做2006年的總結(jié)，似乎有點晚了，畢竟現(xiàn)在陽歷已經(jīng)是2007年2月份了，不過按照老家的傳統(tǒng)，沒過春節(jié)，那還算2006年。按照總結(jié)的慣例，應該是先回顧后展望，所以我也先回顧。這個總結(jié)，只談感受。
06年3月份，開始維護部門的一個新的項目，換了個新的環(huán)境，不過對我而言，接觸的卻不是新的技術。也許現(xiàn)在已經(jīng)不是追新的階段了。
做軟件的都有個習慣，愛接觸新的技術，這幾年JAVA層出不窮的框架，技術太多了，讓人有點應接不瑕。這些東西要是不接觸，有時候還真會被人笑話，毫不例外，我也不落俗套，其實我并不是一個對新鮮事物非常敏感的人，不過有些技術，還是需要了解為好。
06年，接觸的依然是struts，依然是hibernate，依然是spring。抽空看了看JSF,EJB3.0。spring和hibernate依然是那么輝煌，而struts，已經(jīng)開始沒落了。webwork2開始搶風頭，包括現(xiàn)在的struts2，轉(zhuǎn)眼間，已經(jīng)不是我們熟悉的struts了，無非是包裝過后的webwork2，轉(zhuǎn)眼間，也感覺到了時間的流逝。通宵達旦培訓學習struts的時候，已經(jīng)是3年前了。
06年，接觸了領域驅(qū)動設計，讓我明白除了larman的領域模型，原來還有eric的領域模型，可惜目前，我依然是個學習者，而不是一個實踐者。
06年上半年，我虔誠的捧來了martin的重構，可惜到目前為止，那本書還是新的。
06年，也接觸了天書般的分析模式。它當之無愧的當選為我的最佳催眠書，以至于我現(xiàn)在不拿著它睡不著，因為它的確讓我沒看懂。
06年，我依然在看2年前買的UML和模式應用，依然偶爾翻翻1年前買的J2EE核心模式。不過這一年，J2EE核心模式似乎有點輝煌不在了。
頭幾年，感覺一切都是新的，一切都要學。而這一年，感覺進步遠不如前2年了，也許進步更快，我沒有發(fā)現(xiàn)而已。我一直在告戒自己，學習分析與設計不會有學習語言或者框架那種立竿見影的效果，它是一個積累，一個持續(xù)性的過程，我還在等著頓悟分析模式的那一天。
07年，我依然會追隨大師們的腳步。
07年，還要繼續(xù)做點什么。