摘要: 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，这样的作用很明显，节省内存。