应用层缓存　VS　ORM缓存

我个人感觉这样的缓存似乎不会对整体性能有很大的提升.
缓存对于内存的需求倒不是关键.
需要lz实际做出来后仔细测试一下.

在短时间内，更新频繁，但view的操作更频繁，几乎是更新的至少两倍次数以上，

查看一个订单对象时，实际上几乎要load　订单中的所有信息，包括子类的信息。延迟加载是没有用处的。

使用SQL对于记录查询比较好。对于这种单一记录的load，也解决不了问题。

另外，有的时候。数据库压力会逼你采取很多种组合的手段来减小对数据库的查询，尽可能的缓存一切可以缓存的对象，是最便宜的手段。

　　增加硬件，可不是说增加就增加的，直实生活中，作为技术人员除了把程序写好，能够动用的手段是很少的。

　对于整体性能当然有很大的提升了，压力测试时，单个订单页面的频繁的load，对于数据库的压力很小，如果没有缓存，一个订单有８个子对象，加载订单页面时，相当于几十条SQL，DBA肯定要发通报的。

看起来你做过性能测试了.
能否发一下稍微详细点的性能测试对比数据?

对关键任务的应用程序，不应该使用二级缓存，在集群的情况下，如果使用二级缓存，数据不能保证100%的同步，将会出现不可预测的错误。
象楼主所面对的情况，每天5万的数据量对数据库来说，应该说事小菜一碟。如果性能瓶颈在于数据库，应该在数据库方面考虑，如缓存全表，数据库集群，根据业务需求，优化表的设计。

优化应该从SQL入手，一个订单有８个子对象，一个或两个SQL可以搞定的事，用HIBERNATE 要用几十条SQL,性能当然受影响了。

本人使用HIBERNATE多年，发现它最适合用于单个的save,和 update,对于查询，还是JDBC 最好，当然要经过一些封装。

你可以自己设计一个订单，有８到９个子类，再设计对应的一对多或一对一的库表，然后看看，是否可以用一个或两个SQL搞定，并且封装的很好。

sorry, 测试不是俺做的，load runner的测试脚本，也不在我的机子，所以暂时不能提供。

对于这样的应用层缓存及测试，其实太过于特定的应用，所以大可以不必相信及在其它项目当中采纳。

其实的我关键就是想知道，有没有人做过类似于对商业对象发生更新时，不清缓存，直接更新缓存的做法。

要不要給你的哪段table schema 來, 順便講一下你用的是哪個DBMS
看能不能一兩句搞定.

因为Hibernate的executeUpdate会通知整个cache region失效，这种操作很频繁地话，会导致cache miss rate非常的高，你前面也说了: 所以二级缓存变相直接起的作用很少。

Hibernate的executeUpdate并不适合用在这种场景下，每天分配给一个人的订单总是很有限的，按照用户选中的order id，一个一个取出Order对象，然后依次更新并不是什么耗时的操作，如果真有性能上的问题，也可以通过设置合适的batch size来解决。而且你这里采用的bulk update语句里面含有in，这会给数据库带来很大的压力。



你的事务边界是在DAO上？如果在应用层调用多个DAO的话，如何控制事务啊？

这是这个应用比较特殊的地方，订单在更新操作时，就是封装在DAO层内，没有也不允许跨DAO调用。
另外由于没有对SessionInView模式做对压力测试（在生产环境上不能随便做压力测试），得出是否适合这种操作环境，不敢贸然使用，所以延迟加载都是关闭的状态，订单的所有的对象加载，都是在DAO层内完成。