Variables Scope Replacement in Handlers


I recently had a corrective revelation where I came to understand that the variables scope within a handler is shared among all instances of the handler. I had thought that - akin to a singelton - the variables scope would be specific to the individual instance of the handler. So I need to use a different scope within the handler to share variables among all internal functions without a race condition occurring when multiple instances of the handler are in use. What scope would seem to be the most logical?

  • This and variables are out, of course.

  • rc would require passing the event argument to every function, but it seems like it should be unnecessary, e.g. that there should be an easier way to mimic the variables scope in a true instance of a class (i.e. cfc).

  • Perhaps the request scope, though I may be calling the handler from a gateway event from time to time (I know, not the correct usage of a handler, but it’s where I’m at).

  • Would the thread scope be specific to each calling of the handler so long as they come from different requests or gateway events?

  • Maybe form, though that would feel like a bit of a bastardization of the form scope… and does form even exist in an event gateway?
    Rather than spend a while testing different solutions, I figured someone here had likely run into a similar issue and determined what the best course was. I look forward to hearing your suggestions.


Use prc. (rc should be reserved for user input). The Private Request Collection is designed to be your “request scope” of sorts inside the ColdBox framework and it’s automatically available to all action methods, all views, and all layouts. If you have a lot of extra methods in your handlers that aren’t proper actions, those should really be in services but that’s sort of a another conversation.

> I had thought that - akin to a singelton - the variables scope would be specific to the individual instance of the handler

That sentence doesn’t make any sense-- a singleton, by definition, is only created once for the entire application and that single instance is shared for the entire app. So as you have found, there is only one instance of a handler CFC created. The only place it is safe to store variables specific to a single request is in a method local or method arguments scope. And for what it’s worth, the rc and prc structs are pass in the arguments scope which makes them safe.



ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

ColdBox Platform:


prc is available to Actions in the handler, but if you end up creating helper functions within the handler, it is not available to them unless you specifically pass it as an argument.

You are correct on singletons… my misunderstanding undermined me. One of those instances where 20 years of work doesn’t always fill in gaps in not having a formal degree in programming.