Should I use Spring Session Scoped beans or a cache such as ehcache?

Question

We have an app that needs to maintain state so that some objects containing data (potentially a lot) can be interrogated by a client (browser) in a 'conversational' interaction. It would not be efficient to reload the data with with each request.

We use Spring and session scoped beans to maintain some session controlled data. However these new beans would be larger.

Would this be an appropriate use of session scoped beans or would a cache (ehcache) be better suited?

We're reluctant to pull in a caching technology unless we really have to.

The other factor is that the app will need to be deployed in a cluster. In which case would session scoped beans be replicated by the application server's session replication or, would it be more efficient to use ehcache (which I believe can be distributed in a cluster)?

Any guidance appreciated.

Answer 1

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.