摘要: Apache commons IO包中提供了一個可以遍歷目錄下資源的DirectoryWalker，還有很多的IOFileFilter用于過濾文件目錄。下面的例子分別演示了這個功能。
注意這個過程是可以被cancel的。cancel主要有2種情況。外部cancel：外部線程通過調用內部類的cancel()方法。內部cancel：在handleDirectory、handleFile中主動拋出CancelException。
walk方法在每次執行前、后都會檢查當前是否有cancel指令發出(checkIfCancelled ---> handleIsCancelled)，如果有那么默認立刻拋出CancelException，然后調用handleCancelled方法。
從
同一個源文件(15M左右)使用不同的方式讀入，一種是讀入后構造成一個String，另外一個是讀入后構造成一個List。然后再調用
writeLines(File, String)和writeLines(File, Collection)寫入。下面是測試比較的結果：
Read and write by string format
File sizes(bytes): 15661680
Content read(bytes): 15661680
Time costing(ms) on reading: 2047
Time costing(ms) on writing: 1016
Read and write by collection format
File sizes(bytes): 15661680
File read(lines): 1782615
Time costing(ms) on reading: 2047
Time costing(ms) on writing: 533437
效率相差之多! 我的測試環境如下：
OS：Win XP SP4
CPU：Intel Core(TM) 2 Duo CPU
內存：800M(虛擬機分配)
JDK：JDK 5.0 (JVM內存分配：-Xms64m -Xmx512m)
測試文件：15.295M (是一個IP地址文件，總共1782615行)
在讀方面時間居然相當(這里面應該有操作系統層面的緩沖作用，我單獨地測試時第2個方式總比第一個慢1/3左右)。而在寫方面性能簡直是天壤之別啊：533437/1016 ≈525倍。
雖然我這個測試還是不嚴謹的，但是從方法實現過程和原理來看，兩者性能差異存在必然的因素：
①以Collection方式去構造的，在讀取的過程中生成多個小String，而生成String是一項耗時的工作
②以Collection方式去寫的，首先要迭代這個Collection，然后每次調用Collection中的元素的toString()方法，造成多次的堆棧操作
摘要: 最近在對之前做過的一個項目進行二期修改。鑒于之前典型的貧血結構，以及Controller--->Service--->DAO模式讓代碼壓力都集中在service層的情況。在參考了Banq寫的幾篇對象職責和Domain Event的文章后，我也試著搗鼓了一下新的分層模式。貼出來和大家討論，歡迎拍磚！
摘要: 樂觀鎖定采用的版本策略實際上和SVN的版本沖突解決方案是同樣的：采用其它人的(先提交的)、采用自己的(后提交的)、合并他人和自己的(合并沖突更新)
摘要: READ COMMITITED：不允許讀取未提交的數據，但可以讀取已提交的數據。所以可能出現不可重復讀、和幻像讀(讀的過程依然可以被修改、增加、刪除)
REPEATABLE READ：通過行鎖定，在讀的數據不允許其它進程修改。確保已讀取的數據不被修改、刪除(不可重復讀)但無法阻止其它進程寫入新數據，所以不能確保讀取到新的數據(幻像讀)
摘要: 一級、二級緩存使用的key均為po的主鍵ID，value即為po實例對象，查詢緩存使用的則為查詢的條件(hql轉化而成的sql語句)、查詢的參數、查詢的頁數，value有兩種情況，如果采用的是select po.property這樣的方式那么value為整個結果集，如采用的是from這樣的方式那么value為獲取的結果集中各po對象的主鍵ID，這樣的作用很明顯，節省內存。