Hey Reed, Try replacing your test.cfm with this: -------------------------------- <cfobject type="JAVA" name="obj" class="java.lang.Thread" action="CREATE">
<cfdump var="#session#"> <cfset session.x=1> <cfdump var="#session#"> <cfoutput>#timeformat(now(),"HH:MM:SS")#</cfoutput> <cfset obj.sleep(70000)> <BR><BR> <cfoutput>#timeformat(now(),"HH:MM:SS")#</cfoutput> <cfdump var="#session#"><br> <cfoutput>x=#session.x#</cfoutput><br> <cfset session.x=2><br> <cfoutput>x=#session.x#</cfoutput><br> -------------------------------- You can set values to the session even after it's expired (with one exception, see below), but these will hold only for the execution of the current page - touching a session after it's expired will not bring it back to life, sorry, no night of the living dead sessions (apologies all, I couldn't quite resist that)! The exception to the rule - if "Use J2EE session variables" is off on your administrator, execution will proceed with no problems. However, if it's on, an exception will be thrown trying to set session.x after the session has timed out. This is because the reference to the the session object maintained by CF has been cleared from the associated J2EE session. Ashwin -----Original Message----- From: [EMAIL PROTECTED] [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 26, 2006 11:06 PM To: CF-Talk Subject: Re: What determines session inactivity timeouts? OK, I did what I should have done before starting this thread, which was to rig up a test case to see what happens. Pretty interesting results. It appears that CF keeps the session vars alive during page processing, even if there is no activity with those vars. Here is what I did: In Application.cfm: <cfapplication name="test" clientmanagement="no" sessionmanagement="yes" setclientcookies="yes" setdomaincookies="yes" sessiontimeout="#createtimespan(0,0,1,0)#" applicationtimeout="#createtimespan(0,1,0,0)#" loginstorage="session"> In Test.cfm: <cfobject type="JAVA" name="obj" class="java.lang.Thread" action="CREATE"> <cfdump var="#session#"> <cfset session.x=1> <cfdump var="#session#"> #timeformat(now(),"HH:MM:SS")# <cfset obj.sleep(70000)> <BR><BR> #timeformat(now(),"HH:MM:SS")# <cfdump var="#session#"> HERE IS WHAT HAPPENED: First time I executed test.cfm, I got three CFDUMPS of the session scope: dump 1 had no vars in it, dumps 2 and 3 showed the var I set in my code. Since there was a 70 second pause between 2 and 3, and the session var timeout was set to 1 minute, that tells me that CF kept the session vars alive. I waited 2-3 minutes and reran, with the same output - which shows that CF did in fact destroy the session vars after the 60 second timeout occured between the two page requests. Then I ran another variation: I ran the script again, and then when it finished I reran it immediately, and guess what - the session var was gone! That makes it look like CF kept the session var alive during the script's execution, even though the timeout was reached, but deferred destroying the var until the request completed. So I did another scenario: ran the same test in 1 browser, but with the pause set to 2 minutes, and immediately in another browser window ran a script that simply did 2 CFDUMPs of the session scope with a 60 second pause between them. The second window (which began and ended during the first window's 2 minute pause period), showed the session var to be alive on both dumps. I refreshed it's screen immediately, and when it finished the session var was gone. This tells me that when CF "deferred" destroying the session var during the first script's execution, it kept the var alive for all other requests, not just for the currently executing one. Final test - I changed the second script's pause to be 2 minutes, and waited about 10 seconds after running the first script before starting the second, to see what happens to the session vars for the second script when it it still running after the first script ends. The session vars for the second script were still there on both dumps, which is pretty interesting because it said that when CF saw that the second script was running it kept the session vars alive, even though it never touched any of them. But the immediate rerun of the second script showed that the vars were gone as soon as it had finished. Bottom line is that session vars don't dissapear out from under you during script execution, but when the lifeguard blows the whistle the session vars are gone as soon as the last guy is out of the pool - unless someone new jumps into the pool and actually touches a session var. Whew Reed >It is possible that the delay could occur while processing a single CF >tag, therefore, you would have no way of "touching" a session variable. > >For example, the session timeout is 5 minutes. On the page, you have a >CFFILE tag that save a huge amount of data to a text file. It could >take 7 minutes to save the file. By the time the CFFILE tag completes, >the session has expired. > >There is no way to "hook" into the CFFILE tag and have it restart the >session timer. > >I just wonder if the session timer is reset after EVERY session >variables read/write or only once when the page is requested/completed. >There is probably an easy way of testing this by setting a session >variable, sleeping the thread for several minutes (to let the session >timeout), then trying to read the same session variable and see if it >still exists. > >M!ke > >-----Original Message----- >From: Shawn McKee [mailto:[EMAIL PROTECTED] >Sent: Wednesday, April 26, 2006 9:00 AM >To: CF-Talk >Subject: RE: What determines session inactivity timeouts? > >As developers do we have access to these session variables? If so why >not just update them manually every so often during page processing? >You could also over ride the system time out with a cfsetting tag for >these specific pages since you know they may run long. > >Shawn McKee ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:238846 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
