关于second level cache的研究

又是一个周末，的晚上。一个人，在办公室。听着Enya的歌，突然想写点什么。也就有了这个我的在blogdriver上的第一篇blog。
我想记录一下，今天通过写测试代码获得的对于ehcache的认识。
前天，我决定就现在的需求——超级频繁的大访问量——使用ehcache。一同改动的还有c3p0的数据库连接池。
首先，session的cache是固有的，如果不做close，那当然还在同一个session中了。
这个很明显的样子，呵。可是在我以前的模式下，无法体会到这正是局限性所在。以前的需求可以想象为整个sessionFactory中只有一个session。（这也得归咎于曾经采用的需求->设计..的模式，后来我给老板推荐了《软件需求管理：用例方法》一书）
那么，在看了robbin的两篇关于cache的文章，*无数遍以后，有点开窍了。当然还有另一篇关于建议使用query cache的文章。

测试的前提：
对象数据库有15个类，时间为运行100次的时间，每一次包括打开和关闭当前session。亦即会创建100个session。会有30个class和147个collection

测试的结果是这样子的：
(表格显示有问题)
使用ehcache时 不管class cache和collection cache是否在hbm.xml中申明 运行query cache所需时间为33秒左右
使用ehcache时 不管class cache和collection cache是否在hbm.xml中申明 每次清空缓存 运行query cache所需时间为32秒左右
不是用ehcache 时间为41秒左右
我现在的认知是这样子的：
1、在hbm.xml中的配置仿佛无关紧要，系统自然会在第一次（每个life中的第一次）去加在second level cache中。和时间上冲突不大，很难说谁优谁劣。
2、配置与否的ehcache的动作都是检查缓存中是否存在了一个没有过期的该对象。分散这样的注意力反而好一点点。
3、evict对性能的影响不大。删除内存的数据还免得去比较了，当然是好一点。如果随时都清空岂不是和直接用session本身的一样了？但是时间上少了些许，是不是说明ehcache的效率好一点？还是和query cache有关？