3

Question for the crowd. We are very strict on our team about scoping local variables inside functions in our CFC's. Recently though the question of scoping variables inside Application.cfc came up. Are unscoped variables in functions like onRequestStart() at the same risk for being accessed by other sessions running concurrently as we know that local variables in functions in other components are? Or are they somehow treated differently because of the nature of the functions in Application.cfc?

James A Mohler
  • 11,060
  • 15
  • 46
  • 72
Rob Barthle
  • 376
  • 2
  • 9
  • note: If you have `onRequest()`, variables scope of `onRequestStart()` would be shared with the variables scope of the included page. – Henry Nov 18 '11 at 20:13
  • Thanks Henry. But would scoping them as variables.varName be scping them simialr to using the LOCAL scope? – Rob Barthle Nov 19 '11 at 01:14
  • I guess so, if ColdFusion behaves sanely. :) Otherwise you found another non-thread-safe bug. – Henry Nov 19 '11 at 01:54

1 Answers1

13

Your question borders on two entirely separate questions (both of which are important to clarify and address). These two questions are:

  1. Should I scope my variables correctly when referring to them (ie. APPLICATION.settings vs. SESSION.settings).

The short answer to this is: Yes. It makes for cleaner, more readable / managable code, and prevents variable scope clashes that you may encounter later when variable names are re-used.

If you create APPLICATION.settings and SESSION.settings, but attempt to refer to them without scope (ie. <cfset myvar = settings />), you're going to have variable clash issues, as they'll be poured into VARIABLES by default--since neither APPLICATION nor SESSION are examined to resolve scope ambiguity.

The second question is:

  1. Should I be worried about variables that are accessed in Application.cfc that could be potentially be shared by multiple users in a concurrent environment?

The short answer to this is: Yes. You should know & understand the ramifications of how your shared variables are accessed, and <CFLOCK> them where appropriate.

Unfortunately, exactly when and where you lock your shared variables is often never clarified to the CF community, so let me sum it up:

  1. onApplicationStart() single-threads access to the APPLICATION scope. You do not need to lock APPLICATION vars that are read/written within this method.
  2. onSessionStart() single-threads access to the SESSION scope. Same answer as before.
  3. If you provide any kind of mechanism that accesses SESSION or APPLICATION from within the onRequestStart() method--or any other template afterwards (such as a URL reload parameter that directly calls onApplicationStart() )--all bets are off--you must now properly handle the locking of your shared variable reads and writes.
Shawn Holmes
  • 3,752
  • 22
  • 25
  • My question was not about application or session scoped variables, although your explanation of the single threading nature of onApplicationStart() and onSessionStart() was something I was not aware of. We lock those scopes when changing values, but don't when reading them. We also try to only read them once per request if possible to minimize chances of any issues. I am well aware of the importance of noting the scopes in accessing them. – Rob Barthle Nov 19 '11 at 01:10
  • The code in question is legacy, and when you look at it, it is used as a variables-scoped variable would be used. I guess that leads to another question, is noting them as variables.varName properly scoping them? I know the LOCAL scope is a reserved scope for other components for locally scoping variables in a function. How would that work in an onRequestStart() kind of function I wonder. – Rob Barthle Nov 19 '11 at 01:12
  • Added clarification. Hope this answers remaining ambiguities. – Shawn Holmes Nov 19 '11 at 20:03
  • Damn dude. You should write a book. :) Thanks! – Rob Barthle Nov 21 '11 at 18:18
  • Thank you! I did actually...but it was on C++ O.o – Shawn Holmes Nov 22 '11 at 15:45
  • +1 great explanation of this incredibly poorly understood area of CF. One little thing though, the `APPLICATION`, `SESSION` and `SERVER` scopes are not searched when resolving un-scoped variables, and as such can only be accessed through explicit reference. See http://stackoverflow.com/questions/1152248/in-coldfusion-variables-are-resolved-in-what-order – Daniel Mendel Dec 17 '12 at 16:52
  • 1
    @DanielMendel Good catch! I glossed over this, and have edited my response near the start to improve clarity around scopes that aren't examined during ambiguity resolution. – Shawn Holmes Dec 18 '12 at 17:33
  • There is a rebuttal from @seancorfield https://github.com/framework-one/fw1/issues/159#issuecomment-12483431 – J.T. Mar 05 '15 at 20:08
  • Whatever tests I ran back in '11 to confirm the edge condition of REQUEST being modified by concurrent incoming threads before exiting onRequestStart() escapes me. I built a new test with Railo, and it supports @seancorfield, so I have backed that portion of my answer out to prevent confusion. – Shawn Holmes Mar 07 '15 at 01:49