我使用的是GEF0.10(http://gef.tigris.org)，在某一個Fig上點擊鼠標右鍵彈出PopupMenu時，發(fā)現(xiàn)有閃爍的現(xiàn)象，經(jīng)過追查發(fā)現(xiàn)，一個鼠標右擊動作會分別觸發(fā)Editor.mousePressed(e)、mouseReleased(e)、mouseClicked(e)三個事件，這些事件最終都要流經(jīng)ModeManager，而ModeManager采取的是廣播的方式分發(fā)這些事件，把這些事件依次轉發(fā)給mode對列中的所有Mode。ModePopup是默認的一個Mode之一，負責提供Fig的彈出菜單功能。而ModePopup中的這三個事件都作了如下的判斷：
public void mouseClicked(MouseEvent me) {
boolean popUpDisplayed = false;
if(me.isPopupTrigger() || me.getModifiers() == InputEvent.BUTTON3_MASK) {
popUpDisplayed = showPopup(me);
if (LOG.isDebugEnabled()) {
if (popUpDisplayed) LOG.debug("MousePressed detected as a popup and popup displayed and event consumed");
else LOG.debug("MousePressed detected as a popup but no popup to display");
}
return;
}
LOG.debug("MousePressed is not a popup trigger");
}
其中加紅的這段不知道為什么要作me.getModifiers() == InputEvent.BUTTON3_MASK的判斷，加上這個判斷后只要是鼠標右擊動作，ModePopup的mousePressed、mouseReleased和mouseClicked事件中showPopup的代碼都要被執(zhí)行，這樣在一個鼠標右擊動作中實際上彈出了三次PopupMenu，因此造成了閃爍。解決辦法是extend默認的ModePopup，覆蓋這三個方法，將判斷改成if ( me.isPopupTrigger())即可。
今天做了一個測試，發(fā)現(xiàn)Hibernate的dynamic-update只在兩種條件下生效：
1。同一session內(nèi)，對已經(jīng)persisit的對象進行update，這里的“已經(jīng)persist”是指update之前先進行了create或者load調(diào)用。代碼示例：
Session session = openSession();
User user = (User)session.load(User.class,new Long(12));
user.setAddress(null);
session.update(user);
session.flush();
將hibernate配置成show_sql=true，可以看到update產(chǎn)生的sql語句。
2。不同session之間，update傳入的對象是另一個session中的persist對象（對該對象調(diào)用了create或者load方法）。代碼示例：
Session session1 = openSession();
User user = (User)session1.load(User.class,new Long(12));
Session session2 = openSession();
user.setAddress(null);
session2.merge(user);
session2.flush();
如果將session2.merge(..)改成update，則會更新所有可更新的屬性。
今天在csdn上看到了一篇介紹PDCA理論在項目管理中應用的blog，很是感慨，想想才到公司的時候老總也給我們做過相關培訓，一年下來，要是沒有看到這篇blog，鐵定是想不起來了。PDCA（計劃、實施、檢察、優(yōu)化）是一個很好的理論，現(xiàn)摘錄這篇blog的內(nèi)容如下，以為珍藏。
以下內(nèi)容出自：http://blog.csdn.net/wwwxuhong/archive/2004/12/20/222804.aspx
項目管理是個很大的課題
所有的事物都有其規(guī)律
項目管理的規(guī)律是什么？
前幾天看到一個理論讓我眼睛一亮，陳述如下，希望對大家有點啟發(fā)
PDCA循環(huán)是由美國統(tǒng)計學家戴明博士提出來的，它反映了質(zhì)量管理活動的規(guī)律。P（Plan）表示計劃；D（Do）表示執(zhí)行；C（Check）表示檢查；A（Action）表示處理。PDCA循環(huán)是提高產(chǎn)品質(zhì)量，改善企業(yè)經(jīng)營管理的重要方法，是質(zhì)量保證體系運轉的基本方式。
項目管理的PDCA環(huán)。
PDCA是指以下四個階段，這四個階段是環(huán)環(huán)相扣的，這個周期是周而復始的
P Plan 計劃
D Do 實施
C Check 檢查
A Action 總結、再優(yōu)化
不管是多大的項目，還是多小的任務，如果都用PDCA環(huán)實施，環(huán)環(huán)相扣，就可以大大提高管理的質(zhì)量，最大程度地保障項目的成功實施。
PDCA分以下八上步驟
計劃階段
1、分析現(xiàn)狀
2、找出問題的原因
3、分析產(chǎn)生問題的原因
4、找出其中的主要原因
5、擬訂措施計劃
實施階段
6、執(zhí)行技術組織措施計劃
檢查階段
7、把執(zhí)行結果與預定目標對比
總結、再優(yōu)化階段
8、鞏固成績，進行標準化
轉貼一篇相關文章
在企業(yè)中，通過眾多小小的變革可能實現(xiàn)對整個企業(yè)的持久改善，從而獲得巨大的成效。這在日語中叫做“改善”（kaizen），每一步都很小，這兒一個小變化，那兒一個小改進，但幾年后就能發(fā)展出完全不同的產(chǎn)品、工序或服務。
PDCA循環(huán)是由美國統(tǒng)計學家戴明博士提出來的，它反映了質(zhì)量管理活動的規(guī)律。P（Plan）表示計劃；D（Do）表示執(zhí)行；C（Check）表示檢查；A（Action）表示處理。PDCA循環(huán)是提高產(chǎn)品質(zhì)量，改善企業(yè)經(jīng)營管理的重要方法，是質(zhì)量保證體系運轉的基本方式。
PDCA循環(huán)的特點PDCA表明了質(zhì)量管理活動的四個階段，每個階段又分為若干步驟。
在計劃階段，要通過市場調(diào)查、用戶訪問等，摸清用戶對產(chǎn)品質(zhì)量的要求，確定質(zhì)量政策、質(zhì)量目標和質(zhì)量計劃等。它包括現(xiàn)狀調(diào)查、原因分析、確定要因和制定計劃四個步驟。
在執(zhí)行階段，要實施上一階段所規(guī)定的內(nèi)容，如根據(jù)質(zhì)量標準進行產(chǎn)品設計、試制、試驗，其中包括計劃執(zhí)行前的人員培訓。它只有一個步驟：執(zhí)行計劃。
在檢查階段，主要是在計劃執(zhí)行過程之中或執(zhí)行之后，檢查執(zhí)行情況，看是否符合計劃的預期結果。該階段也只有一個步驟：效果檢查。
在處理階段，主要是根據(jù)檢查結果，采取相應的措施。鞏固成績，把成功的經(jīng)驗盡可能納入標準，進行標準化，遺留問題則轉入下一個PDCA循環(huán)去解決。它包括兩個步驟：鞏固措施和下一步的打算。
PDCA循環(huán)四階段各步驟。
1.PDCA循環(huán)一定要按順序進行，它靠組織的力量來推動，像車輪一樣向前滾進，周而復始，不斷循環(huán)。
2.企業(yè)每個科室、車間、工段、班組，直至個人的工作，均有一個PDCA循環(huán)，這樣一層一層地解決問題，而且大環(huán)套小環(huán)，一環(huán)扣一環(huán)，小環(huán)保大環(huán)，推動大循環(huán)。
這里，大環(huán)與小環(huán)的關系，主要是通過質(zhì)量計劃指標連接起來，上一級的管理循環(huán)是下一級管理循環(huán)的根據(jù)，下一級的管理循環(huán)又是上一級管理循環(huán)的組成部分和具體保證。通過各個小循環(huán)的不斷轉動，推動上一級循環(huán)，以至整個企業(yè)循環(huán)不停轉動。通過各方面的循環(huán)，把企業(yè)各項工作有機地組織起來，納入企業(yè)質(zhì)量保證體系，實現(xiàn)總的預定質(zhì)量目標。因此，PDCA循環(huán)的轉動，不是哪一個人的力量，而是組織的力量、集體的力量，是整個企業(yè)全體職工推動的結果。
3.每通過一次PDCA循環(huán)，都要進行總結，提出新目標，再進行第二次PDCA循環(huán)，使質(zhì)量管理的車輪滾滾向前。PDCA每循環(huán)一次，質(zhì)量水平和管理水平均提高一步。
PDCA循環(huán)不僅是質(zhì)量管理活動規(guī)律的科學總結，是開展質(zhì)量管理活動的科學程序，也是一種科學管理的工作方法。它同樣可以在質(zhì)量管理活動以外發(fā)揮重要效用。
PDCA管理法在營銷中的運用在運用PDCA循環(huán)進行市場營銷管理方面，已經(jīng)有一些優(yōu)秀企業(yè)走在了前頭。
海爾集團純熟地采用PDCA管理法來實施銷售任務的計劃、組織和控制。每年年終，集團商流、各產(chǎn)品本部根據(jù)本年度的銷售額完成情況，結合各產(chǎn)品的發(fā)展趨勢及競爭對手分析等信息，制定下一年度的銷售計劃，然后將這一計劃分解至全國11個銷售事業(yè)部。銷售事業(yè)部長根據(jù)各工貿(mào)上年的完成情況、市場狀況分析等信息再將銷售額計劃分解至其下屬各工貿(mào)公司。工貿(mào)公司總經(jīng)理將任務分解至各區(qū)域經(jīng)理，由他們將任務下達至區(qū)域代表，區(qū)域代表將自己的銷售額任務分解至其所管轄的營銷網(wǎng)絡。同時，海爾還從時間緯度上進行分解：年度計劃分解至月度，月度計劃分解至每日。這樣，處于管理層的每位管理者都可以對下屬每日的工作狀況進行監(jiān)督，并及時實施糾偏，最終控制每一個具體網(wǎng)點。海爾集團在新產(chǎn)品開發(fā)、新品上市等所有方面都遵循PDCA管理方法。這種做法可以保證“人人都管事，事事有人管”，避免出現(xiàn)管理的真空。
PDCA管理法運用于每日的事務管理，就形成了獨具海爾特色的OEC日清體系。每人均處于相應的崗位上，每一崗位均有不同的職責，并分配相應的指標，員工的激勵直接與指標掛鉤。指標又可分為主項指標與輔項指標以及臨時任務指標等。每人在當日晚上分析一天的各項任務完成情況，并找出差距原因及糾偏辦法，以使今后的工作質(zhì)量得到提高，由此構成了持續(xù)不斷的改進過程。員工在做完當日總結后，對明日工作做出計劃，然后將OEC日清表交至主管領導處，由主管領導進行審核控制并對下屬的當日工作進行評價和激勵。
OEC管理法的主要理念，海爾認為是“堅持兩個原則，最大限度地對待兩種人”，即堅持閉環(huán)原則，堅持優(yōu)化原則，最大限度地關心員工的生活，最大限度地滿足用戶的需求。所謂閉環(huán)原則，指凡事要善始善終，都必須遵循PDCA循環(huán)，而且是螺旋上升。所謂優(yōu)化原則，指根據(jù)木桶理論，找出薄弱項，及時整改，提高全系統(tǒng)的水平。在一個企業(yè)的運營過程中，必然存在著許多環(huán)節(jié)，只要找出制約企業(yè)經(jīng)濟效益提高的某一關鍵環(huán)節(jié)，把首要矛盾解決了，其他矛盾就可以迎刃而解。
張瑞敏說，海爾生產(chǎn)線每天要出大大小小幾萬臺家電產(chǎn)品，我們不能考慮出了問題如何處理，而要追求不出任何問題。OEC管理法把質(zhì)量互變規(guī)律作為基本思想，堅持日事日清，積沙成塔，使員工素養(yǎng)、企業(yè)素質(zhì)與管理水平的提高寓于每日工作之中，通過日積月累的管理進步，使生產(chǎn)力諸要素的組合與運行達到合理優(yōu)化的狀態(tài)，不增加投入就可使現(xiàn)實生產(chǎn)力獲得盡可能大的提高，從而令管理收到事半功倍的效果。
海爾把PDCA運用到企業(yè)內(nèi)部的營銷隊伍管理上，那么，這種管理方法對外部營銷是否適用呢？
上海通用汽車公司成功地把此方法應用于自己的經(jīng)銷體系中，極大地改善了經(jīng)銷商的服務。在其近100家經(jīng)銷商中，上海通用奉行的政策是，對一些業(yè)務表現(xiàn)不好、不能完成上海通用的要求、不能在市場上進行有效的開拓，或者在售后服務方面不能夠完全按照上海通用的理念和規(guī)范去操作的經(jīng)銷商，會先給他們做一個PDCA改進計劃。完成了這個計劃性的四部曲后，經(jīng)銷商的整個市場營銷的管理工作應該會隨之步入一個良性循環(huán)的軌道。如果還是不行，經(jīng)銷商就會被淘汰掉。
由上可知，PDCA管理法的核心在于通過持續(xù)不斷的改進，使企業(yè)的各項事務在有效控制的狀態(tài)下向預定目標發(fā)展。
先前的項目采用的是TyrexFactory作為事務工廠的實現(xiàn)，但是運行的過程中發(fā)現(xiàn)很不穩(wěn)定，處理大對象時容易出現(xiàn)事務超時的錯誤，即使事務設置的超時時間很長也是這樣，將jotm及其相關jar copy 到lib中之后，換成JotmFactory，發(fā)現(xiàn)TransactionFactory.getTransactionFactory竟然報NoSuchElementException。后來發(fā)現(xiàn)是carol.jar中的CarolConfiguration需要裝載jndi.properties文件進行初始化，而tyrex.jar自身有一個同名的文件，正是因為CoralConfiguration裝載了這個同名的文件才產(chǎn)生了異常，去掉tyrex.jar就可以了。
Ofbiz2.1有兩個bug，都涉及到線程安全性，小并發(fā)的時候不容易發(fā)現(xiàn)，大并發(fā)下有時候會出現(xiàn)，并發(fā)數(shù)越高出現(xiàn)的頻度就比較高，尤其對于實體引擎的那個bug，在系統(tǒng)初始化的時候如果遭遇大并發(fā)，會有一定頻度的出現(xiàn)。
1。entity engine的ModelEntity.getField方法存在線程安全隱患，會造成 XXXX is not a field of XXX的異常，以下是原有代碼片斷：
public ModelField getField(String fieldName) {
if (fieldName == null) return null;
if (fieldsMap == null) {
fieldsMap = new HashMap(fields.size());
for (int i = 0; i < fields.size(); i++) {
ModelField field = (ModelField) fields.get(i);
fieldsMap.put(field.name, field);
}
return (ModelField) fieldsMap.get(fieldName);
}
由于getField方法沒有同步（會造成性能下降），因此紅色標標注的那段代碼存在線程安全問題，必須進行同步。在大并發(fā)下如果多個調(diào)用這個方法，最先調(diào)用的線程沒有執(zhí)行完循環(huán)的情況下，后續(xù)的線程通過最后的語句return的時候得到的就是Null（fieldsMap已經(jīng)被第一個線程賦值了，后續(xù)線程不會進入紅色標準的代碼區(qū)域）。
修改后的代碼如下：
public ModelField getField(String fieldName) {
if (fieldName == null) return null;
if (fieldsMap == null) {
createFields();
}
return (ModelField) fieldsMap.get(fieldName);
}
public synchronized void createFields()
{
fieldsMap = new HashMap(fields.size());
for (int i = 0; i < fields.size(); i++) {
ModelField field = (ModelField) fields.get(i);
fieldsMap.put(field.name, field);
}
}
這個Bug在3.0中已經(jīng)被修正。
2。UtilCache.get方法同樣存在線程安全隱患，會造成LinkedList.remove或者LinedList.addFirst的空值針異常，不注意還會以為是LinkedList的bug。以下是原代碼片斷：
public Object get(Object key) {
if (key == null) {
missCount++;
return null;
}
UtilCache.CacheLine line = (UtilCache.CacheLine) cacheLineTable.get(key);
if (hasExpired(line)) {
// note that print.info in debug.properties cannot be checked through UtilProperties here, it would cause infinite recursion
// if (Debug.infoOn()) Debug.logInfo("Element has expired with key " + key);
remove(key);
line = null;
}
if (line == null) {
// if (Debug.infoOn()) Debug.logInfo("Element not found with key " + key);
missCount++;
return null;
}
// if (Debug.infoOn()) Debug.logInfo("Element found with key " + key);
hitCount++;
if (maxSize > 0) {
keyLRUList.remove(key);
keyLRUList.addFirst(key);
}
return line.getValue();
}
紅色標準的部分是有問題的代碼，修改后的代碼如下：
public Object get(Object key) {
if (key == null) {
missCount++;
return null;
}
UtilCache.CacheLine line = (UtilCache.CacheLine) cacheLineTable.get(key);
if (hasExpired(line)) {
// note that print.info in debug.properties cannot be checked through UtilProperties here, it would cause infinite recursion
// if (Debug.infoOn()) Debug.logInfo("Element has expired with key " + key);
remove(key);
line = null;
}
if (line == null) {
// if (Debug.infoOn()) Debug.logInfo("Element not found with key " + key);
missCount++;
return null;
}
// if (Debug.infoOn()) Debug.logInfo("Element found with key " + key);
hitCount++;
if (maxSize > 0) {
synchronized ( this)
{
keyLRUList.remove(key);
keyLRUList.addFirst(key);
}
}
return line.getValue();
}
這個BUG在3.0種也修正了。
1。XAPool是如何wrap jdbc driver返回的PreparedStatement的。
以下是StandardConnectionHandler中的checkPreparedCache代碼片斷
????synchronized?PreparedStatement?checkPreparedCache(
????????String?sql,
????????int?type,
????????int?concurrency)
????????throws?SQLException?{
????????log.debug(
????????????"StandardConnectionHandle:checkPreparedCache?sql='"?+?sql?+?"'");
????????PreparedStatement?ret?=?null;?//?the?return?value
????????//?NOTE?-?We?include?the?Connection?in?the?lookup?key.?This?has?no
????????//?effect?here?but?is?needed?by?StandardXAConnection?where?the?the?physical
????????//?Connection?used?can?vary?over?time?depending?on?the?global?transaction.
????????String?lookupKey?=?sql?+?type?+?concurrency;
????????//?used?to?lookup?statements
????????if?(preparedStatementCache?!=?null)?{
????????????Object?obj?=?preparedStatementCache.get(lookupKey);
????????????//?see?if?there's?a?PreparedStatement?already
????????????if?(obj?!=?null)?{?//?if?there?is
????????????????ret?=?(PreparedStatement)?obj;?//?use?as?return?value
????????????????try?{
????????????????????ret.clearParameters();?//?make?it?look?like?new
????????????????}?catch?(SQLException?e)?{
????????????????????//?Bad?statement,?so?we?have?to?create?a?new?one
????????????????????ret?=?createPreparedStatement(sql,?type,?concurrency);
????????????????}
????????????????preparedStatementCache.remove(lookupKey);
????????????????//?make?sure?it?cannot?be?re-used
????????????????inUse.put(lookupKey,?ret);
????????????????//?make?sure?it?gets?reused?by?later?delegates
????????????}?else?{?//?no?PreparedStatement?ready
????????????????ret?=?createPreparedStatement(sql,?type,?concurrency);
????????????????inUse.put(lookupKey,?ret);
????????????????//?will?get?saved?in?prepared?statement?cache
????????????}
????????}?else?{
????????????ret?=?createPreparedStatement(sql,?type,?concurrency);
????????}
????????//?We?don't?actually?give?the?application?a?real?PreparedStatement.?Instead
????????//?they?get?a?StandardPreparedStatement?that?delegates?everything?except
????????//?PreparedStatement.close();
????????ret?=?new?StandardPreparedStatement(this,?ret,?lookupKey);
????????return?ret;
????}
2。StandardPreparedStatement的Close方法代碼片斷
????public?void?close()?throws?SQLException?{
????????//?Note?no?check?for?already?closed?-?some?servers?make?mistakes
????????closed?=?true;
????????if?(con.preparedStmtCacheSize?==?0)?{
????????????//?no?cache,?so?we?just?close
????????????if?(ps?!=?null)?{
????????????????ps.close();
????????????}
????????}?else?{
????????????con.returnToCache(key);
????????????//?return?the?underlying?statement?to?the?cache
????????}
????}
3。xapool StandardPoolDataSource的getConnection 原理：
??
?? StandardPoolDataSource.getConnection --> GenericPool.checkOut-->StandardPoolDataSource.create -->StandardPoolDataSource.getPooledConnection：返回StandardPooledConnection。?
???? StandardPooledConnection通過StandardDataSource.getConnection獲取jdbc driver返回的connection（physical connection），然后通過工廠方法newConnectionHandle采用StandardConnectionHandler對該connection進行包裝。StandardConnectionHandler對PreparedStatement進行重新包裝和Cache，對connection.close進行了控制。
?
4。xapool StandardXAPoolDataSource的getConnection的原理：
?? StandardXAPoolDataSource.getConnection -->StandardPoolDataSource.getConnection-->StandardXAPoolDataSource.create -->XADataSource.getXAConnection -->StandardXADatasource.getXAConnection：返回StandardXAConnection。
??? StandardXAConnection通過StandardDataSource.getConnection獲取jdbc driver返回的connection（physical connection），然后通過工廠方法newConnectionHandle采用StandardXAConnectionHandle對該connection進行包裝。StandardXAConnectionHandler繼承自StandardConnectionHandler。
?
5。xapool從StandardPoolDataSource獲取的 Connection的關閉原理。
?? StandardPooledConnection.close-->StandardConnectionHandler.close（設置closed=true，回收PreparedStatement）-->StandardPooledConnection.closeEvent-->StandardPoolDataSource.connectionClosed-->GenericPool.checkIn（返回連接池）
?
6.xapool中對連接池進行管理的類是GenericPool，該類的checkOut和checkIn方法分別完成連接獲取和連接回收功能。checkOut從unlocked池中獲取可用的連接，如果需要進行檢查或者測試，然后返回；如果發(fā)現(xiàn)unlocked池中沒有連接，在連接數(shù)小于maxSize的時候調(diào)用PoolHelper的實現(xiàn)類創(chuàng)建連接，如果連接數(shù)已經(jīng)達到或者超過maxSize，調(diào)用wait使當前進程進入等待狀態(tài)（等待期限和等待間隔可以設置），如果等待過程中其他線程釋放了connection返回可用的connection，否則異常：GenericPool:checkOut ERROR? impossible to obtain a new object from the pool
- sleepTime：PoolKeeper檢測時間間隔
- lifeTime：連接生命周期（上次訪問時間-當前時間）
- deadLockMaxWait(：超過最大連接之后的調(diào)用getConnection的等待時間
- deadLockRetryWait：超過最大連接之后的調(diào)用getConnection等待，在等待中重試的時間間隔
- maxSize：連接池的容量
deald-lock-max-wait和dead-lock-retry-wait的設置要小心，這兩個參數(shù)的意義見我的另一個日志：XAPool原理簡要分析。dead-lock-retry-wait最好設置得比較短，這樣不至于線程等待很長時間，dead-lock-max-wait的設置不要太長，一般是設置成比最高并發(fā)數(shù)下應用處理時間稍長一點，設置過短在大并發(fā)下會造成提交實效導致應用數(shù)據(jù)的丟失，因為超過xapool在超過等待dead-lock-max-wait之后會異常：沒有可用連接分配。
sleepTime是對Connection idle檢測線程PoolKeeper的檢測時間間隔設置。PoolKeeper會定時監(jiān)測是否存在超過lifeTime的connection然后釋放掉這些connection。不過PoolKeeper在運行的時候會檢查running屬性，以下是它的run方法中的代碼片斷：
while (! running && !Thread.interrupted()) {
System.err.println("!!!!"+System.currentTimeMillis());
try {
synchronized (this) {
wait(this.sleepTime); // wait for timeout ms before attack
}
} catch (InterruptedException e) {
break;
}
this.pool.cleanUp(); // clean up the Pool and reallocate objects
}
// release the pool.
this.pool = null;
之所以把這段代碼粘出來，是因為running屬性默認是true，而GenericPool在啟動PookKeeper的時候并沒有改變這個值，因此PookKeeper永遠不會運行起來。也許這是xapool的另一個bug：）
連接池的容量設置是有講究的，一般至少等于AppServer（或者叫WEB 容器）的最大并發(fā)數(shù)。因為xapool在達到maxSize的時候，如果還有線程需要連接，會進入等待狀態(tài)（通過deadLockMaxWait設置最大等待時間，deadLockRetryWait設置等待間隔），在大并發(fā)下會造成App Server容器線程池滿，Server在一段時間內(nèi)（deadLockMaxWait）停止響應的現(xiàn)象。將連接池的容量設置成大于App Server的最大并發(fā)數(shù)，可以盡可能的避免這種情況。App Server的最大并發(fā)數(shù)=App Server的線程池線程數(shù)，Tomcat默認是75，Websphere默認是50。集群環(huán)境下，集群的最大并發(fā)數(shù)=每臺集群服務器的最大并發(fā)數(shù)之和
現(xiàn)狀：我們的項目中使用了ofbiz2.1，并采用JotmFactory作為TransactionFactory，使用Oracle9i數(shù)據(jù)庫，在大并發(fā)測試的時候發(fā)現(xiàn)數(shù)據(jù)庫游標暴漲并且不釋放，最終導致游標溢出。
原因分析：ofbiz entityengine的很多操作都是使用PreparedStatement完成的，這無可厚非，問題是JotmFactory采用的是XAPool作為連接池，而XAPool對PreparedStatement進行了Cache，同時Oracle有一個出名的內(nèi)存漏洞，PreparedStatement使用之后必須關閉，如果不關閉連續(xù)進行SQL查詢會造成前面SQL的游標不能釋放；此外JotmConnectionFactory沒有允許對XAPool做更多的配置，按照它使用XAPool的方式，XAPool會對PreparedStatement進行Cache。Oracle漏洞+ofbiz的不周全的使用方式+xapool的機制造成了游標不釋放最終溢出的異常。
解決辦法：修改JotmConnectionFactory，調(diào)用StandardXAPoolDataSource的setPreparedStmtCacheSize(int)的方法，將preparedStmtCacheSize設置為0。需要注意的是xapool在目前的版本（1.4）當preparedStmtCacheSize=0的時候存在一個bug，close PreparedStatement的時候會報NullPointerException，請參考我的另一個日志
XAPool1.4的bug。
現(xiàn)狀：XAPool1.4有一個bug，當設置preparedStmtCacheSize=0的時候，關閉連接會拋出NullPointerException
原因：StandardConnectionHandle在Close的時候調(diào)用了preparedStatementCache.cleanupAll()，沒有進行判斷；而當preparedStmtCacheSize設置為0的時候，StandardConnectionHandle在setupPreparedStatementCache中把preparedStatementCache設置為null，以下setupPreparedStatementCache是方法中的源代碼片斷：
protected void setupPreparedStatementCache() {
log.debug("StandardConnectionHandle:setupPreparedStatementCache start");
if (preparedStmtCacheSize == 0) {
log.debug(
"StandardConnectionHandle:setupPreparedStatementCache return with 0");
preparedStatementCache = null;
return;
}
解決辦法：修改setupPreparedStatementCache，如下：
if (preparedStmtCacheSize == 0) {
log.debug(
"StandardConnectionHandle:setupPreparedStatementCache return with 0");
// preparedStatementCache = null;
preparedStatementCache = new PreparedStatementCache(0);
return;
}
現(xiàn)狀：在我們的項目中使用了Ofbiz2.1，TransactionFactory配置為JotmFactory，數(shù)據(jù)庫是Oracle9i，lifeTime設置為120000（2分鐘）在大并發(fā)測試的時候發(fā)現(xiàn)經(jīng)常Closed Connection的異常。
原因：Oracle數(shù)據(jù)庫會檢查physical connection的idle時間和使用次數(shù)并關閉長時間idle的physical connection，如果應用對從連接池中
獲取的connection不進行檢查，或者連接池仔返回可用連接之前不進行檢查，在使用過程中就會Closed Connection的異常。大多數(shù)數(shù)據(jù)庫都會檢查physical connection的idle時間。
解決辦法：調(diào)用StandardPoolDataSource或者StandardXAPoolDataSource的setCheckLevelObject(int)方法設置連接檢查級別，參數(shù)取值如下：
-
0:不檢查
-
1:對unlocked池中獲取的連接進行Closed檢查
-
2:對unlocked池中獲取的連接進行sql測試，需要設置setJdbcTestStmt(Test SQL)
-
3:對所有unlocked池中的連接進行Closed檢查
-
4:對所有unloked池中的連接進行測試，需要設置setJdbcTestStmt(Test SQL)