Database – Storing large data in HTTP Session (Java Application)

databasedesignsessionweb-applications

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

I am planning to follow this approach.

When user add product to cart, create a Cart Model, add items to cart and save to DB.
Convert Cart model to cart data and save it to HTTP session.
Any update/ edit update underlying cart in DB and update data snap shot in Session.
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?

Best Answer

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:

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

Drawbacks to a global Map as a cache:

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

Related Solutions

Database – HTTP Session or Database approach

I would go for a solution where an unique ID is assigned to all visitors when they first hit the site. It doesn't matter if they're anonymous or authenticated. When anonymous users register, retain the unique ID.

Store the shopping cart in the database. Storage is cheap, and it shouldn't be a problem performance-wise to do a query for the cart every now and then.

Java – Designing application flow

When I look at your use case, I start thinking about separation of concerns.

The controller shouldn't care if the cart is in the request or not.
The service call that adds Items to a cart shouldn't care if the user is logged in or not.

I then think:

Request objects are a pain in the butt to test with
A Facade feels kind of vague for specific use cases. What if we could create a simple Data Transfer Object for each use case that has the data needed?

So I would start with something like:

Controller

Status addItemToCart(HttpServletRequest request, Item item) {
  if(request.getSession(false) == null) return needLogin(request)

  UserCart cart = service.addItemToCart(item, new UserCart(session))
  return cart.saveToSession(session)
}

Service

UserCart addItemToCart(Item item, UserCart userCart) {
  if userCart.needsCart() {
     userCart = cartDAO.getNewCart(userCart)
  }
  userCart.addItem(Item)
  return cartDAO.updateCart(userCart)
}

My Service layer tests would insist on something like UserCart to keep me from having to mock HTTPServletRequests and create 10 lines of setup code. UserCart is just a dumb Data Transfer Object with some convenience methods, but it makes everything much simpler to understand. User has-a shopping cart is important to this use case, so it's where my brain goes pretty quickly. This also allows us to avoid all the null checks and nested blocks that become rampant when you go out of your way to avoid creating simple domain specific concepts.

Best Answer

Related Solutions

Database – HTTP Session or Database approach

Java – Designing application flow

Related Topic