這幾天一直在被乙個問題糾結：乙個stateful session bean的例項變數中儲存了乙個resultset的例項，但是，當這個例項在該bean的乙個方法中被建立後，從該方法返回後卻發現這個resultset例項被關閉了。
這個問題我最初的第一直覺是，一定是什麼地方呼叫了resultset的close方法。經過，一次又一次的除錯斷點可以斷定沒有呼叫這個方法。這時候覺得似乎和事務相關，覺得是某次呼叫丟擲了異常，導致事務退出。但是，現在再想想，即使是有異常，也不是根本原因。根本原因還是事務相關。
由於一直沒有明確的思路，這個問題就放了幾天一直到昨天。這次我決定把之前down掉的除錯環境搭建起來。因為我的呼叫是從另乙個虛擬機器發起。現在，想想這一步也不是必須的。其實完全可以找到那個方法的呼叫點，打上斷點就可以斷定是從哪個分支過來的。
確定了上游呼叫邏輯後，思路就清晰起來了： stateful session bean中定義的幾個方法是業務方法，在乙個上游方法中，被依次呼叫。問題是，第乙個方法a建立並保持了乙個resultset的例項，後續的方法b,c都依賴於這個resultset例項。當方法b被呼叫時，報了乙個錯：resultset already close。
此時，我開始關注這個bean的事務，它是容器管理的事務。型別是required。上游呼叫方法是乙個普通類的方法沒有事務關聯，所以，每次呼叫方法a就會重新發起乙個事務。這時候，我想是不是因為這裡的問題？每次方法返回，事務就終結於是在事務中建立的resultset例項就close了。
現在的疑問是這個問題是怎麼引入的？聯想到系統剛剛公升級到了ejb3,很多配置從xml檔案一道了類中。於是檢視了原來的配置檔案，發現原來事務的型別是bean，但是bean中並沒有用到事務，所以相當於沒有事務。現在，公升級的時候把它搞錯了寫成了container。
重頭梳理這個問題的解決思路，其實如果先去看改動歷史應該能很快的確定問題所在。我也確實這麼做了，但是只看了類檔案的改動歷史沒有看配置檔案。還是，問題定位的不準確。
關於綜合查詢的效能優化問題的解決乙個思路
在專案中，總是會有什麼什麼列表查詢，然後還要求根據型別分類查詢，有時候發現不同型別關聯的表不相同，想要獲得的東西也不相同，之前我查詢方法總是採用union 將幾個相關表連線起來，這樣造成的問題是，壓力全部在資料庫上，後來根據領導的建議，我將相同的基表先查出來，然後，採用for迴圈將不同關聯的表按條件...
乙個sql問題的解決
表內容 2005 05 09 勝 2005 05 09 勝 2005 05 09 負 2005 05 09 負 2005 05 10 勝 2005 05 10 負 2005 05 10 負 輸出 比賽時間 勝 負 2005 05 09 2 2 2005 05 10 1 2 自己完成建表語句，插入語句...
關於Top n演算法問題的乙個思路
top n問題一直是面試熱點，舉個栗子，100000個無序數字，怎麼找出最大的前10個？如果用氣泡排序的話，就要比較100000 100000次，很顯然不行，這是最差的情況下，那麼最好的情況也要至少遍歷一遍，也就是100000次，所以，複雜度就是越接近十萬次越好。可以這樣 取前十個數，用插入排序從大...