我们使用Spring和会话作用域Bean来维护一些会话控制数据。然而,这些新的bean将更大。这是否是会话作用域Bean的适当用法?还是缓存(ehcache)更适合?
我们不愿意引入缓存技术,除非我们真的必须这样做。另一个因素是应用程序需要部署在集群中。在这种情况下,应用程序服务器的会话复制是否会复制会话作用域Bean,或者使用ehcache(我相信可以在集群中分布)更有效?
任何指导都将不胜感激。
关于此事的一些想法(免责声明:我在terracotta/ehcache工作...所以请记住这一点...但仍然试图保持公正):
1 - 每个会话中是否存在任何冗余数据?有没有什么可以在会话之间共享的东西?如果有,+1使用ehcache存储共享内容(因为ehcache针对重度并发进行了优化)
2 - 你的会话对象有多大?你预计在稳定状态下会有多少并发用户?(换句话说,你将不得不为会话存储在应用服务器上的内存分配多少空间?)
如果会话占用的空间总体上不是很大,并且可以很好地适应堆内存而不会出现GC问题,那么使用会话应该是一个不错的解决方案。
但是它变得越大,你的Java堆就需要更大...并且你将不得不使用巫术技巧来保持垃圾收集和GC暂停时间的控制。 通过使用ehcache,您可以集中存储一些多个会话可以访问的对象...从而 consololidating您的内存占用(与1相同) 此外,通过使用ehcache的企业扩展(BigMemory=http://terracotta.org/products/bigmemory),您可以绕过堆限制并将数据存储在堆之外(尽可能多-10s、100s GB或更多)。有了这个,需要在内存中的对象的大小变得无关紧要(当然,只要您可以向服务器添加RAM)
3 - 对于会话复制,像JBOSS、Weblogic、Websphere这样的应用服务器都支持它。同样,这又是一个会话大小的问题(需要在网络上复制多少数据)。如果您的会话对象很大,并且您有许多这样的对象,那么在您的集群中将会有大量的网络流量...可能会或可能不会工作得很好。 在分布式EhCache层中拥有核心对象来优化数据存储,同时将会话保持到最小(即登录/身份验证信息),我认为肯定会增强会话复制机制。
希望这可以帮助到您。