I am currently supporting an old java web application that is causing me a lot of pain. This application makes heavy use of session object and almost everything is stored in the session object. Users of the system have reported problems where in a record when opened has details of some other record, I am assuming that session is picking up the wrong record.

I wanted to redesign the applciation so that it makes less use of teh session object, what are the possible design approcahes that I can use to reduce session usage? The application does not use any new frameworks liek struts/spring.
 The application is running on tomcat.
Also if I dont store the information on the session then where should I store it?

asked 07/04/2010 09:12

youneverknoweverything's gravatar image

youneverknoweverything ♦♦

11 Answers:

Please give us more details.  
>almost everything is stored in the session object.
Tell us what kind of data is being stored there. Is it strictly user data ?
>where in a record when opened has details of some other record  
What kind data is it. Is it details that pertain to a specific user ?
Is it data that pertains to the application ? If yes, then there is application scope that could be used.



rrz@871311's gravatar image


The data pertains to specific jobs assigned to a particular user. The user is stored in t he session as welll as the jobs. When user clicks a particular job it might open a different one for him.

Do you mean that I can remove the data from the session and put it in another object which is similar to session like application scope? How does struts/spring handle this?


answered 2010-07-04 at 17:32:34

youneverknoweverything's gravatar image


>The data pertains to specific jobs assigned to a particular user.
How do you have jobs and users set up in your database ?
>How does struts/spring handle this?  
I don't use either of those. Hopefully an expert will comment about them.
I use JDO.  Specifically    


answered 2010-07-04 at 18:01:05

rrz@871311's gravatar image


With Struts/Spring or any web framework, the recommended usage is to store the data in HTTP request if it is going to be stateless. Suppose the user clicks on a job in page 1 and you need to start it; but you do not require job details in page 2. Then in this case, you can store the job details in REQUEST scope on submit of page 1, process it and the data is discarded after the request is processed.

However, if you require that the job details be carried over more than 1 page, then the only option is to use page. I would suggest some kind of a filter/base class that takes care of cleaning up session(remove unused objects)  after each call.


answered 2010-07-04 at 18:58:49

anilallewar's gravatar image


Most probably you will want to implement a sort of "page sequence" scope, where your data will be physically stored in a Session context but will be aggressively removed from it where certain event occurs, i.e. an action is executed or the user navigated to another page, signalling the end of the page sequence.

A request listener is a possible way to implement it.

With it, you will get a s cope narrower than Session but wider than Request. You may want to allow only one or multiple concurrently running "page sequence" scopes.


answered 2010-07-05 at 00:16:06

Hegemon's gravatar image


less use of session - Thats a very detable question; what qualifies as less use of session? How does that solve the users seeing different sessions issue?

Thinking along these lines, the only way to avoid that is to actually not use the session at all! However I take that what you intend is to separate the relationship between a session cookie and the user-specific data. There are a few ways to do that

- As metioned by others, use View State (also knows as Request state). Save the user-id in encrypted form on the client side. Make sure it is submitted along every request. Use that as the user identifier.

- Use, url rewriting. The user-id (enc form) becomes part of the URL. The front controller or simple .htaccess rules can transform it into a request variable. So for example your url might look like ASP.NET already has url rewriting an option whereby the session id is not stored in a cookie but becomes part of URL. An IIS filter hook dll does the job of transforming it into session id.

On the other hand, considering the option of using "less session", some options are (these make sense if you look at it from resource usage perspective + persistency + web-farms/clusters etc.)

- Keep bulk of the session data on file system. PHP for example, keeps it on disk. Use the data access patterns analysis to check which data is less urgent/least use and put it there. Cleaning up disk can then be performed as a scheduled task.

- Keep it in DB or a state server like ASP.NET has one.

- Keep it in a distributed/clustered cache like JBoss Cache for example. Works well in a clustered environment.


- Use a hybrid approach and mix all the ideas for various types of data.

Hope that helps ...


answered 2010-07-05 at 05:01:20

ambience's gravatar image


thanks for all your answers, will it be easier to write a new application based on struts/spring rather than fixing the code everywhere, I can not remove unused values form sesison because everywhere the code uses session to get the values.


answered 2010-07-07 at 13:46:14

youneverknoweverything's gravatar image


See if you are undecisive about it, how can we tell whats best when we haven't even seen the problems.

- Is applying any of the suggestion supplied so far is a viable option?

I see two core issues
- Bad sessions. (More critical than unused values IMHO)
- Too much saved in session. (Though you didnt say anything about resource bottlnecks).

Its easy to stick with the "build again using XYZ framework" idea, but a cost-benefit analysis can only tell whats more feasible. Just one question: Whats least costly, rewrite or fix?



answered 2010-07-07 at 15:44:51

ambience's gravatar image


Check to see that the session.invalidate() is called when a user logs off.  If not then you need to call it.


answered 2010-07-07 at 16:53:05

ProgSysAdmin's gravatar image


Build again will need analysis of the existing application flow completely. So while doing that if you segregate the sessions in two parts used and unused through out application, then you can come to a conclusion. Suppose if there is a lot of data in the sessions that are unused, if you can discard those from the existing application, then building new is not at all required.

So, best thing first do the analysis on existing application, identifies the scopes of the session data, based on that clear the session data where ever you can and clear unnecessary sessions.

Even after doing this if you are facing issues, then the analysis itself will give you proper approach.

answered 2010-08-12 at 20:29:25

padmakaraa's gravatar image


This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.


answered 2010-12-08 at 01:08:58

leonstryker's gravatar image


Your answer
[hide preview]

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments



Asked: 07/04/2010 09:12

Seen: 309 times

Last updated: 12/11/2011 05:18