In a system I am currently developing I am using HttpSessions heavily to store data retrieved from the database, mainly to be used for page iteration. The problem I have is the risk of using up server memory, if an unexpected number of users perform large queries and do not log out of the system. I've added limits to the maximum number of records that can be retrieved and stored in an iterator helper, but still feel uncomfortable with the open-endedness of the memory requirements. Ideally the HttpSession API would include expiry of session attributes, either based on the time added or the last time accessed. However there doesn't appear to be such a luxury. I am considering writing a session attribute manager that would purge the session attributes over time, but am wary of managing all the references to HttpSession objects and the stored attributes. Does anybody have any strategies to recommend? I look forward to your advice.
The first thing you can do is to reduce the session timeout value. As far as I know all modern web servers provide this facility. Also these days all the webserver use Hard disk space, when they require. So response could be slow,but it won't run out of memory for a normal application with reasonable number of users. yup you can't rely on the single server, when you think of scalability.Other important thing what I'm using in my application is I don't fetch all the records at one time from database and put them in session, rather I have written a class,so that I can get specified number of reocrds at one time from DB only. So it's all about using the session object properly.
Joined: Jan 15, 2003
Thanks for the tips. I feel a lot more confident about the situation now. I have set my sessions to never expiring and instead use a session manager to invalidate the sessions. This is so I can manage HTTP and non-HTTP sessions in the same place, and also have greater flexibility at monitoring and logging sessions. I don't see any problems with this arrangement. I hadn't thought that sessions might be written to the hard disk, which certainly changes the situation. It looks quite rosy now that I quanitify the memory requirements: the bulk of the users, customers, only access one type of listing page and have short sessions, which will limit the main volume of the session attributes. The non-customers have very long sessions, up to a week, but there would be perhaps only half a dozen of them logged in at any time. I have made the maximum number of records configurable and expect I'll set it to something like one thousand. This is restricted by an SQL helper called by the iterator, so doesn't restrict back-end usage that must access all applicable records. Based on this I could calculate the expected memory use as: Number of customers logged in at any time X number of iterators per customer held in memory X maximum number of records per iterator X record size + Number of non-customers logged in at any time X number of iterators per non-customer held in memory X maximum number of records per iterator X record size ==> 100 X 1 X 1000 X 200 bytes + 6 X 5 X 1000 X 200 bytes ==> 20,000,000 bytes + 6,000,000 bytes ==> 26 MB (using 1MB==1,000,000B) No worries there Hopefully this example calculation can help other programmers out there. Scalability should not be a major issue if we maintain high standards of efficient codes/patterns. Managing sessions in the application will help if we ever need to cluster the application.
Saving session info into secondary storage is certainly not the part of spec. Even if a server supports the saving session to a persistent storage, it should be possible to disable it unless you need some sort of high availablity solution. BTW, which app server are you using?
We'll be using Orion, which I think should support saving session info to secondary storage. Considering my rough calculations of 26MB session data and that we'll probably be running with 1GB of RAM we shouldn't need to depend on this.
Ben, Why are you not using Session time our feature.
Joined: Jan 15, 2003
Pradeep, I do time out the sessions, except I use my own session manager instead of the web container. This is so I can manage both web and non-web (Swing client) sessions in the same place. This works well and sessions are expiring as expected. Do you think this is a bad idea? The issue of purging session attributes applies to users who view large data sets but who remain active enough so that their sessions don't expire.
The session manager is just a simple singleton class. It launches a thread which regularly checks user sessions registered in it, and purges those that have passed their last good time. The session manager doesn't know anything about Http sessions, but listens to session/web container events. Sure, this setup won't work in a clustered application, but that won't be necessary in the foreseeable future. It could easily be attached to or integrated with a Session Bean, and is simple enough to throw away if we need something more sophisticated. The session manager allows for ISG/admin monitoring of user activitiy, and logs all forms of logout (user chooses to logout, forced by system shut-down, session over-written by logging in from another location, forced logout by account suspension). Do you have any comments or advice about this setup? Chances are I've broken some architectual rules, but it serves its purpose and can be dumped if need be. [ July 17, 2003: Message edited by: Ben Williams ]
I understand that Your sessionmanager does the same thing as the web contianer. You talked abt swing clients ? How do they communicate with the server i.e.which protocol. I am not sure whether i can help you much.