Amount of data stored in session

Question

What technique should we use to make the httpsession object not loaded heavily with data.

Example :

Request 1 ---- > httpSession loaded with an arraylist of 50,000 different objects. session.setAttribute("data",arraylist);

Request 2 ---- > httpSession loaded with an arraylist of 40,000 different objects. session.setAttribute("data",arraylist);

Assume the server is loaded heavily with multiple sessions and huge data in them. Let us say from my above example request1..1000 at a time. Which means 1000 session objects with huge data.

What is the alternate way to solve instead storing them in session like this?

Answer 1

Either put it in the application scope instead (if it is not user-specific), or replace by request-based database-side paging/filtering (if it is user-specific).

I suppose that the data is already stored in a database. Putting it in the application scope does not make much sense then. You will always have memory problems when the Java code hauls/copies the entire dataset of a datastore (e.g. a RDBMS) in Java's memory and then do the job right in Java's memory using Java code. It will indeed get worse when you even store/duplicate it in the session scope of a webapplication.

The most memory efficient approach is to let the database do the task where it is invented for. The SQL language offers you under each the ORDER BY clause to do the sorting, the WHERE clause to do the filtering and the (DB vendor specific) LIMIT/OFFSET clauses/subselects/functions to return only a subset of records based on firstrow and rowcount or lastrow. This way you end up with only the dataset in Java's memory which is actually to be displayed.

You can find examples of the needed SQL queries in this answer I posted before here. Hope this helps.

Answer 2

You could set an attribute on the request, or use forms, if you use the data in the view. If you need to have the data when the session is active, put it in a database.

Answer 3

I would suggest you try one of the two alternatives:

• Store the user specific data in your database
• Use a cache system like EhCache or memcached

Answer 4

Store only unique identifiers of objects that are staying in a shared pool (memory, db, flat files)

Answer 5

Some ideas:

1. Be more selective about which data you really need to serve to your client, instead of plonking everything in the Session on the first request you could only load data when the client really needs it (c.q. when a tab is clicked by the user). You can also use specialized lightweight classes instead of your full backend domain classes to pass the data to the frontend.

2. Check your domain model, and see if you can split out any 'static data'. By this I mean data which is commonly shared within your application and does not change a lot, like zipcodes. This type of data is a good candidate for caching and passing by reference, instead of duplicating it.

3. As mentioned, use a caching framework like Ehcache. It reduces the need for plumbing code in your application and allows shared caching across all sessions instead of duplicating the data. Of course if you are only storing user-specific data in your session, then the sharing won't be of big benefit. A framework like that also allows you to configure the caching strategy, for instance so that it will start using the database if necessary.