我们有一个需要维护状态的应用程序，以便客户端（浏览器）可以在“对话”交互中查询一些包含数据（可能很多）的对象。每次请求都重新加载数据效率不高。
我们使用 Spring 和会话范围的 bean 来维护一些会话控制的数据。然而，这些新豆会更大。
这是对会话范围 bean 的适当使用还是缓存（ehcache）更适合？
我们不愿意引入缓存技术，除非我们真的必须这样做。
另一个因素是应用程序需要部署在集群中。在这种情况下，应用服务器的会话复制会复制会话范围的 bean，或者使用 ehcache 会更有效（我相信它可以分布在集群中）？
任何指导表示赞赏。
Couple of thoughts on this (disclaimer: I work for terracotta/ehcache...so keep that in mind...but still trying to be unbiased here):
1 - Is there any redundant data in each of the sessions? Anything that could be shared across sessions? If yes, +1 for ehcache to store the shared stuff (because ehcache is optimized for heavy concurrency)
2 - How big are your session objects going to be? And how many concurrent users are you expecting on a steady state basis? (in other words, how much memory are you going to have to dedicate to session storage on your app server?)
If session footprint is not that big overall and can fit nicely in your heap without GC issues, then using session should be a fine solution.
But the bigger it gets, the larger your java heap will need to be...and the more you'll have to use voodoo tricks to keep garbage collections and gc pause times in check. By using ehcache, you can store centrally some objects that multiple sessions could access...hence consolidating your memory footprint (same point as 1) Additionally, by using the enterprise extension for ehcache (BigMemory=http://terracotta.org/products/bigmemory), you can bypass Heap limitations and store your data off-heap (as much as needed - 10s, 100s of GB or more). With that, the size of the objects that need to be in memory become irrelevant (as long as you can add RAM to your server of course)
3 - For session replication, app servers such as JBOSS, Weblogic, Websphere support it. Again, it's a matter of session size again (how much data will need to be replicated across the wire). If you session objects are big, and you have many of them, there will be a lot of network traffic across your cluster...could or could not work well. Having core objects in an distributed EhCache layer optimized for data storage, while keeping your session to a minimum (i.e. login / authentication information) would definitely enhance that session replication mechanism in my opinion.
Hope that helps.