I am asking this question in continuation with http-session-or-database-approach.

I am planning to follow this approach.

  1. When user add product to cart, create a Cart Model, add items to cart and save to DB.
  2. Convert Cart model to cart data and save it to HTTP session.
  3. Any update/ edit update underlying cart in DB and update data snap shot in Session.
  4. When user click on view cart page, just pick cart data from Session and display to customer.

I have following queries regarding HTTP Session

  • How good is it to store large data (Shopping Cart) in Session?
  • How scalable this approach can be ? (With respect to Session)
  • Won't my application going to eat and demand a lot of memory?
  • Is my approach is fine or do i need to consider other points while designing this?

Though, we can control what all cart data should be stored in the Session, but still we need to have certain information in cart data being stored in session?

  • 4
    Could you specify what exactly you mean with “saving to HTTP session”? Cookies, local storage in the browser, your database, or something completely different?
    – amon
    Commented Oct 17, 2013 at 19:10
  • 1
    I believe that typically one uses a cache (ehcache for example) between the database and the server. The cache tends to be a bit more intelligent with fetching and storing data rather than trying to put it all in the session.
    – user40980
    Commented Oct 17, 2013 at 19:33
  • @amon: generally session data is stored as heap size allocated to JVM.Though container can write session data to disk, but only when low in memory. Commented Oct 18, 2013 at 2:17
  • @MichaelT: That is one of option i was thinking of, but have to cross check it. Commented Oct 18, 2013 at 2:18

2 Answers 2


I'm going to assume you are referring to the HttpSession object and not a J2EE Session bean object.

If you have just one server, then the Session is just like a sort of global Map that can be accessed whenever your user makes a request. Large objects or small objects, either way, they can be put in the map, but depending on how long you leave them there they can be problematic.

Most application servers remove sessions that have expired, so if you expect visitors to leave the site after a while, then perhaps you don't need to do any session maintenance and you can just let the sessions expire, and the application server will clean up after you.

However, if you expect that a lot of users will remain on the site for a long time, and could potentially have these long-lasting objects in their sessions, and you might not have enough memory to handle this, then you need some other approach.

The simplest approach might be to use some kind of LRU cache. You could, for example, use the commons LRUMap which lets you set a maximum size on the map and removes items that it no longer needs. This way, you can have a global cache for your large objects, and if you have too many users then the cache simply drops data. Performance suffers if there are a lot of cache misses, but at least everything still functions properly.

At the end of the day, if you don't have enough ram to cache stuff and enough database bandwidth to handle the misses, your app is going to crash no matter what tricks you use.

The drawbacks to using the HttpSession:

  1. If you have multiple servers, it complicates fail-over or load balancing.
  2. Sessions, if long-lived, can be a sort of memory leak, where data is cached there and never read or cleaned up.
  3. Sessions are not shared per-user, so they are not useful as general-purpose caches.

Drawbacks to a global Map as a cache:

  1. You have to clean up the data yourself, or use a third-party library which does the cleanup.
  2. If you have multiple servers, users need to stay on the same server in order to benefit from the cache.
  3. However unlike Sessions, if there is data that can be shared per-user, it's easy with a global map.

I think the general pattern is try to store the least information possible in memory, only store the useful data only. This approach would make your application scalable.

If you really want an scalable application, you should build it on an app server, like JBoss/Wildfly or any other Java EE Container.

Design considerations in Java EE is to keep session beans as light as possible.

  • I can not bind my application design to specific app server :( Commented Oct 18, 2013 at 17:27
  • @UmeshAwasthi It will work in every Java EE container theoretically.
    – jacktrades
    Commented Oct 18, 2013 at 17:28
  • @UmeshAwasthi anyhow, if you want to go for scalable, don't store too much in session objects.
    – jacktrades
    Commented Oct 18, 2013 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.