这样的数据该不该用2级缓存？

（一）Hibernate的二级缓存策略的一般过程如下：
1) 条件查询的时候，总是发出一条select * from table_name where …. （选择所有字段）这样的SQL语句查询数据库，一次获得所有的数据对象。
2) 把获得的所有数据对象根据ID放入到第二级缓存中。
3) 当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照ID放入到缓存。
4) 删除、更新、增加数据的时候，同时更新缓存。
　　Hibernate的二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。为此，Hibernate提供了针对条件查询的Query Cache。
（二）什么样的数据适合存放到第二级缓存中？
1 很少被修改的数据
2 不是很重要的数据，允许出现偶尔并发的数据
3 不会被并发访问的数据
4 参考数据,指的是供应用参考的常量数据，它的实例数目有限，它的实例会被许多其他类的实例引用，实例极少或者从来不会被修改。
（三）不适合存放到第二级缓存的数据？
1 经常被修改的数据
2 财务数据，绝对不允许出现并发
3 与其他应用共享的数据。

原文摘自http://rujingzhang.iteye.com/blog/219487

我们项目中A表的情况是这样的 ：
表A的数据只有当天添加的数据是有效的，如果没有当天的数据
那么选择“最近的”数据作为参考显示给用户，
用户可以在页面上点击某按钮获得当天数据，此时，系统访问XX服务器，得到数据并向A表插入一条数据，然后显示用户。
这是向A表insert数据唯一入口，并且A表的数据不会被update和delete

我现在想给A表中的数据缓存，并且DAO中的所有查询方法都控制为只查询3天之内的数据（查询3天之前的数据没有意义）

我的理解是这样的

（二）什么样的数据适合存放到第二级缓存中？
1 很少被修改的数据 会比较频繁的insert，但不会update，不知道算不算很少被修改
2 不是很重要的数据，允许出现偶尔并发的数据  没有 update 操作，所以不存在并发

3 不会被并发访问的数据 没有 update 操作，所以不存在并发

4 参考数据,指的是供应用参考的常量数据，它的实例数目有限，它的实例会被许多其他类的实例引用，实例极少或者从来不会被修改。 在整个应用中A表的数据使用较为频繁，每天都会有些数据失效，并且随时都会插入新数据

由于以前没有做过并发和缓存方面的工作，不知道A表的情况是否适合做2级缓存，做了缓存后会带来哪些问题，希望大家给点建议
希望投新手帖，隐藏帖的大哥们也能给点意见

既然插入了就不改，而且频繁用到，非常适合放到二级缓存中嘛！