ColdFusion forgets variable within 1 line

1
votes

My company works with ColdFusion and has had this problem in different variations for years now. It's time to get it solved.

The scenario is very simple:

<cfparam name="session.check" default="0">
<cfif NOT isDefined('session.check') OR 
      session.check IS 0>
    <cfset ok=1>
</cfif>

Now ColdFusion throws an error:

Element CHECK is undefined in SESSION. The error occurred on line 18.

For those who can read something out of it, here's the detailed stack trace:

coldfusion.runtime.UndefinedElementException: Element CHECK is undefined in SESSION. at coldfusion.runtime.CfJspPage.resolveCanonicalName(CfJspPage.java:1694) at coldfusion.runtime.CfJspPage._resolve(CfJspPage.java:1612) at coldfusion.runtime.CfJspPage._resolveAndAutoscalarize(CfJspPage.java:1747) at coldfusion.runtime.CfJspPage._resolveAndAutoscalarize(CfJspPage.java:1740) at cfindex2ecfm123677868._factor9(C:\path\index.cfm:18) at ...

If cfparam is used or just a cfset doesn't really matter. Also, this is NOT a simplified example, this very error occured on our server. With no single line between the variable being set and read.

We're running ColdFusion 8.0.1.195765. Any ideas?

Thanks in advance!

4
coldfusioncoldfusion-8
I assume the "checkIS" is a typo? - eaolson
Yes, updated the post. Sorry for the mistake. - Daniel Fuchs
Also, do you have a structclear(session) anywhere in the app? - Dan Roberts
Somewhere, yes. But it is near to impossible that a user may trigger that part of the code at the same time as the example code; and compared to that, correctly timing the two site calls so the StructClear on site 2 is being processed right between the cfparam and the cfif check on site 1 is the least problem. - Daniel Fuchs
Can you put a try/catch around line 18, and serialise the session scope and log it (or if appropriate, just dump it to screen). Is the session scope empty, or is just that variable that's AWOL? - Adam Cameron

4 Answers

1
votes

Try using structKeyExists instead of isDefined

<cfif NOT structKeyExists(session, 'check') OR 
      session.check IS 0>
    <cfset ok=1>
</cfif>
1
votes

2 guesses here.... First, you might be fooled by the line number in error. Look above line 18 - above the code you pasted in the stack or order of execution. Look for another "check" reference.

Meanwhile, this code:

<cfparam name="session.check" default="0">
<cfif NOT isDefined('session.check') OR 
      session.check IS 0>
    <cfset ok=1>
</cfif>

While ok... includes "NOT isDefined('session.check')" ... which given the cfparam ahead of it is superflous. Cfparam should guarantee that the var exists so you should not need the "isDefined". I'm guessing it was put in because of the error.

Guess Number 2

Depending on the application this could also be some sort of race problem - especially if using frames or ajax. Try bracketing the code with a CFLOCK for the session scope:

<cflock scope="session" timeout="4">
   <cfparam name="session.check" default="0">
   <cfif NOT isDefined('session.check') OR 
         session.check IS 0>
       <cfset ok=1>
   </cfif>
</cflock>

This would insure that this code would run on an unaltered session - no guarantees on other code that might hit the session.

0
votes

Do you need to declare a timeout of your session? This one times out in 12 hrs...

 <!--- Create the application --->
 <cfapplication name="MyApp" clientmanagement="Yes"
                sessionmanagement="Yes"
                sessiontimeout="#CreateTimeSpan(0,12,0,0)#"
                applicationtimeout="#CreateTimeSpan(0,12,0,0)#">
        <!--- 
        #CreateTimeSpan(days,hours,minutes,seconds)#
        --->

 <cfparam name="session.check" default="0">
0
votes

Check and ensure your CFApplication name is UNIQUE and distinctive. Best Practices usually end up hashing the current directory to ensure this but you could also try adding a version number too to be absolutely sure. e.g:

<CFAPPLICATION name="myApp_0001_#hash(getCurrentTemplatePath())#">

A distressed server that is restarting constantly too can drop sessions as well but the previous reason is probably the most common cause of this...especially in a shared hosting environment.