Sessions

phani_va has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I want to use Sessions.pm for maitaning state information. I have 3 stage scenario in my web site. stage 1 the user fills a query form and makes some selection stage 2 the cgi script gives a list of items mathching the user criteria.here I want to store the selection made by user in stage 1 for use by script in stage 3 stage 3 when the user clicks on one of the listed items the 2nd script displays the detailed information about the selected item.here I need the selections made by user in stage 1. with sessions I can easily do that.my problem is when do I invalidate the session. If I do it after completing stage 3 then when the user presses the back button to go from stage 3 to stage 2 and comes back again to stage 3 I will loose the session data. If I dont invalidate the session then the DB file which stores the session information will be continuing to grow . the size may not be a problem for quite a while. so any suggestions on what might be the best strategy to invalidate the session thanx phani

Comment on Sessions

Replies are listed 'Best First'.
Re: Sessions by esh (Pilgrim) on Aug 15, 2003 at 17:11 UTC
Maintaining the state information in the URL or in hidden form fields avoids some nasty and difficult to correct problems you may encounter down the road. When you maintain the criteria in a session or cookie there is only one copy of this criteria per user. If a user opens two windows and starts two different queries, then one of the criteria sets will be lost and both windows will end up with the same settings. This can be confusing and frustrating to the user. Storing the state information in something related to that window's history (URL or hidden form fields) keeps their histories distinct as the user would have a right to expect. Avoiding the session strategy also has the benefit of not needing to increase the storage requirements on the server side. This is not to say that sessions are inherenty bad for all purposes. Some of my best applications use sessions. That said, let's assume you are using sessions for some reason (good or bad) and you need to prevent their storage from taking over your hard drive. The standard way to do this is to expire the session after some elapsed period of non-use. For example, if a user of a session does not request a page in 30 minutes, that session can be deleted. There are a couple issues that spring to mind: 1. You will need to store the time the session was last accessed. This needs to be updated every time the session is accessed, even if the other data in the session does not change. This may have performance issues if you have really high volume. In fact, I had to replace Apache::Session (Oracle) with my own hand-optimized session code because of really high traffic. You probably should not worry about this. 2. You will need to create a process which regularly deletes sessions that have not been accessed in the last N minutes. This is fairly simple to do if you are storing one session per file as you can check the timestamp on the file, but requires you to iterate over every single session if you are using one of the Apache::Session variations that hides all the data fields in a single blob. -- Eric Hammond	[reply]
Re: Sessions by erasei (Pilgrim) on Aug 15, 2003 at 17:04 UTC
If you are talking about CGI::Session then you can set the timeout in time, like +3h, instructing it to expire in 3 hours. I _believe_ it would be something like: $session->invalidate("+3h"); Another option would be to have an external script that cleans your DB file every so often. Have a little script that removes sessions that are 5 hours old that is automatically run a few times a day.	[reply]