我们有一个需要维护状态的应用程序，以便客户端（浏览器）可以在“对话”交互中查询包含数据（可能很多）的某些对象。使用每个请求重新加载数据效率不高。
我们使用Spring和会话范围的bean来维护一些会话控制的数据。然而，这些新豆将更大。
这是否适合使用会话范围的bean，或者缓存（ehcache）是否更适合？
除非我们真的需要，否则我们不愿意使用缓存技术。
另一个因素是应用程序需要部署在群集中。在哪种情况下，应用服务器的会话复制会复制会话范围的bean，或者使用ehcache（我认为可以在集群中分发）会更有效吗？
任何指导意见。
答案 0 :(得分：1)
对此有一些想法（免责声明：我为兵马俑/ ehcache工作......所以记住这一点......但仍然试图在这里不偏不倚）：
1 - 每个会话中是否有冗余数据？什么可以跨会话共享？如果是，则为ehcache存储+1以存储共享内容（因为ehcache针对重度并发进行了优化）
2 - 您的会话对象有多大？您期望在稳定状态下有多少并发用户？ （换句话说，您需要将多少内存专门用于应用服务器上的会话存储？）
如果会话占用空间不是那么大并且在没有GC问题的情况下可以很好地适应您的堆，那么使用会话应该是一个很好的解决方案。
但它越大，你的java堆就越大......你需要越多的垃圾收集技巧来控制垃圾收集和gc暂停时间。 通过使用ehcache，您可以集中存储多个会话可以访问的对象...从而巩固您的内存占用（与1相同） 此外，通过使用ehcache的企业扩展（BigMemory = http://terracotta.org/products/bigmemory），您可以绕过堆限制并将数据存储在堆外（尽可能多 - 10s，100s或更多GB）。这样，需要在内存中的对象的大小变得无关紧要（当然，只要你可以将RAM添加到服务器中）
3 - 对于会话复制，JBOSS，Weblogic，Websphere等应用服务器都支持它。同样，这又是会话大小的问题（需要在线路上复制多少数据）。如果会话对象很大，并且您有很多会话对象，那么整个群集中会有很多网络流量......可能会也可能无法正常运行。 在为数据存储优化的分布式EhCache层中拥有核心对象，同时将会话保持在最低限度（即登录/身份验证信息）肯定会增强该会话复制机制。
希望有所帮助。