Regarding Storing large data structures in Session or Request or Context

[Jignesh Gohel]

Hi,

Is it a good practice to store a Map object or any data structure available in Java, containing large number of data(for e.g a result set containing lots of rows obtained by executing a query ) as a SESSION or REQUEST or CONTEXT Attribute and then using that attribute to share data across the web-application in other servlets or jsp pages ??

In one of my application i have implemented it like this.Will it arise any performance issues?? And if yes, then how to share data across the application alternatively.

Please provide me the pros and cons of using this technique...

Thanks

[pascal betz]

depends on "how big" and "how many". it is hard or impossible to tell if something is to much or to big or a problem. you need to profile your app, make some calculations ...

some points:
- the contexts (application, session, request, page) have different lifecycles.
- they also have different "amounts" (one application context, one session per user, and so on)
- store your information in the "shortest" lifecylce possible, do not put information that belongs to the user in a application scope
- if you have a cluster then you need to replicate the session (which is expensive in cases when the session is "big") or use sticky sessions
- be careful when storing JDBC resources in one of the contexts: cleanup/closing might be a problem. think also cases when exceptions occur.
-


pascal

[Rahul Bhattacharjee]

In many articles I have read that its not wise to store large objects in HTTPSession , but they do not explain why is that so?

I have my own explanation for this , so please correct if I am worng.

Actually sessions are objects that reside in the server itself ,they do not travel to the client , only the session id is sent to the client for tracking the subsequent calls from the same user.This is the case when your web tire is not clustered.

In case your web tire is clustered , there is only one session object for each user for the entire cluster.So the session object have to travel to different nodes of the cluster on demand basis.So its good from perfomance point of view to keep less sized data in cluster and remove the objects as soon as they are not required anymore.

hope this helps.

[Edisandro Bessa]

Hi Jignesh,

Talking specifically about large resultsets, a resonable good approach would be to use something like pagination. I mean, you don't need to store the whole resultset as a session attribute or whatever, just store a small amount of data in either page or request attribute and then
re-read the database if the user needs some data which is out of the page you stored in memory.

There're many ways to do so, I recommend you to make a simple google.
[ November 02, 2006: Message edited by: Edisandro Bessa ]

[Ben Souther]

As with any caching situation, the answer is "it depends".
What it depends on is, how people use your app.

If your page displays a report (say Student Master or Customer Master) and the user will typically only be interested in seeing a few rows, it wouldn't make sense to pull thousands of student rows from the data base and cache them all in session. As others have mentioned, use pagination to pull one page worth with each request.

On the other hand, if a your site features personalization and there are things about a user that show up on every screen in the app, it might make more sense to read that data from the the database when the user first logs in and cache it in session. That way, you don't have to repeat the same database query with every single page refresh.

One more example:
Suppose your app is an e-commerce site and the site always shows "This Week's Specials" (a list of products with pricing and product information) on the front page. Lets also suppose that that front page gets significantly more traffic than any other page on the site. In this case, it could make a lot of sense to cache the the list of product rows in application scope. This could potentially eliminate any database traffic on the first and busiest page in the app but still allow it to be dynamic.

[Chetan Parekh]

Ben is right. Jignesh Gohel, tell your business requirments. It will help us to suggest best possible way.
[ November 06, 2006: Message edited by: Chetan Parekh ]