Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at Scotch On The Rocks (SOTR) 2011 (Edinburgh) with: Kev McCabe

Understanding Application And Session Timeouts In ColdFusion

By Ben Nadel on
Tags: ColdFusion

Earlier today, I blogged about ColdFusion 9's new ApplicationStop() method which stops the current application, forcing OnApplicationStart() to be called on the next page request. During my exploration of this new method, I found out that the given Application was reset independently of the Session; meaning, while the Application scope was wiped out and repopulated, the existing Session scopes were left unchanged. When I observed this, I thought for sure it was a bug; but, after testing relative Application and Session timeout values, it appears to be the default behavior.

To test the inherent behavior of Application and Session timeouts, I set up a simple Application.cfc file session management:

Application.cfc

  • <cfcomponent
  • output="false"
  • hint="I define the application settings and event handlers.">
  •  
  • <!---
  • Define the application settings. Notice that our
  • Application timeout is rather small - 10 seconds,
  • while our Session timeout is larger - 5 minutes.
  • --->
  • <cfset this.name = hash( getCurrentTemplatePath() ) />
  • <cfset this.applicationTimeout = createTimeSpan( 0, 0, 0, 10 ) />
  • <cfset this.sessionManagement = true />
  • <cfset this.sessionTimeout = createTimeSpan( 0, 0, 5, 0 ) />
  •  
  • <!--- Define the request settings. --->
  • <cfsetting showdebugoutput="false" />
  •  
  •  
  • <cffunction
  • name="onApplicationStart"
  • access="public"
  • returntype="boolean"
  • output="false"
  • hint="I initialize the application.">
  •  
  • <!--- Initialize the application settings. --->
  • <cfset application.dateInitialized = now() />
  •  
  • <!--- Return true so that the page can load. --->
  • <cfreturn true />
  • </cffunction>
  •  
  •  
  • <cffunction
  • name="onSessionStart"
  • access="public"
  • returntype="void"
  • output="false"
  • hint="I initialize the session.">
  •  
  • <!--- Initialize the session settings. --->
  • <cfset session.dateInitialized = now() />
  •  
  • <!--- Return out. --->
  • <cfreturn />
  • </cffunction>
  •  
  • </cfcomponent>

As you can see, the application timeout is a very small number, only 10 seconds. The session timeout, on the other hand, is much larger, at 5 minutes. Each of the scopes (Application and Session) has an event handler which defines an initialization timestamp. I am using these two timestamps to track the effects of the application timeout on the session timeout in the index file:

Index.cfm

  • <cfoutput>
  •  
  • <h1>
  • Application And Session Overview
  • </h1>
  •  
  • <p>
  • Application initialized:
  • #dateDiff(
  • "s",
  • application.dateInitialized,
  • now()
  • )#
  • seconds ago.
  • </p>
  •  
  • <p>
  • Session initialized:
  • #dateDiff(
  • "s",
  • session.dateInitialized,
  • now()
  • )#
  • seconds ago.
  • </p>
  •  
  • </cfoutput>

As you can see, this test code simply outputs the relative age (in seconds) of each scope - Application and Session - based on the DateInitialized property defined in the Application.cfc. When I run this page for the first few time, I get the following output:

Application And Session Overview

Application initialized: 4 seconds ago.
Session initialized: 4 seconds ago.

As you can see, each scope is the same age.

Then, I waited for more than 10 seconds, waiting for the Application to timeout, and refreshed the page. Here is the output I got:

Application And Session Overview

Application initialized: 0 seconds ago.
Session initialized: 107 seconds ago.

As you can see, the Application scope timed out and refreshed itself on this subsequent page request. However, the Session scope, which had a much higher timeout, did not get altered in anyway.

When I saw the behavior of ApplicationStop(), I was sure that it was a bug; however, based on the testing above, which was done in ColdFusion 8, it appears that the complete independence of the Application scope from the Session scopes is the default behavior of the ColdFusion framework. Now, I am not suggesting that you make it a habit of keeping your session timeouts higher than your application timeouts - it wouldn't make any sense; but, this proves that the ApplicationStop() behavior in ColdFusion 9 is in proper alignment with the default ColdFusion framework behavior.




Reader Comments

After such as you said simple Application.cfc file session management I understood, that I knew very little about it

Reply to this Comment

This example fails with the following error:

Element DATEINITIALIZED is undefined in APPLICATION.


The error occurred in C:\ColdFusion8\wwwroot\PearlDomains\vdoms\storyofjesus_COM\aaa_Application_Timeout_Example\cf~index.cfm: line 11

9 : #dateDiff(
10 : "s",
11 : application.dateInitialized,
12 : now()
13 : )#

Reply to this Comment

If a web application will always be in use, will one always need to use applicationTimeout?
Is it this needed in all apps? Or are there times when its not needed?

Reply to this Comment

@Nich,

You can't *not* use it - you don't have a choice. If you don't define it in the Application.cfc, ColdFusion will use the default value defined in the ColdFusion administrator.

There is no sense of not needing it really; if your application is busy, then your application simply doesn't time out. The defined timeout will never have a negative effect on an often-used application.

Reply to this Comment

Hey Ben,

Perhaps you can help me out with a couple of things...

1) My application is Flex housed in CF. I'm generating XML within my CF pages and loading then into my Flex applications... Some users are encountering and odd behavior that renders some application variables (objects) as undefined here and there. I can't duplicate it enough to understand if it's a session issue or what...

2) Should Application timeout and Session timeout be the same length? Or...

Reply to this Comment

@DColumbus,

First off, your application timeout is typically much larger than your session timeouts; but, it doesn't have to be. If you have a high-traffic site, you could leave your application timeout lower and it would still run fine. The whole point of the high timeout is so that the app doesn't have to load often (which would hold-up user experiences).

As far as the errors, is anything showing up in the Application log files? Or is this something showing up in the FLEX app. What I am wondering is if the error is in the FLEX side or in the CF side. I don't know too much about FLEX, so I wouldn't have much insight on that side.

Reply to this Comment

Ben,

I'm getting a lot more users on my system and the application seems to be bogging down my system.

The session timeout is set to 2 hours and the application timeout set to 1 day. If I lowered my session timeout to 15 minutes and my application to 20 minutes, will that solve my issue? Is that a reasonable timeframe?

Reply to this Comment

@Dcolumbus,

Changing your application timeout shouldn't make a difference since the memory usage of your application doesn't really fluctuate; meaning, there typically isn't anything cached in the application scope that is related to the individual sessions.

Sessions, on the other hand, are directly related to how much memory is used on the server since each session implies more variables used. Lowering yous session timeout should help the matter (by allowing stagnant sessions to release their memory much sooner).

Reply to this Comment

Post A Comment

?
You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.