5 Replies Latest reply on Jun 5, 2006 3:26 PM by acsdirect

    Application Scope vs. Session Scope

    William_At_FAA Level 1
      First, some background.

      We have a clustered server running ColdFusion 6.1 MX, FuseBox 4.0. We cannot upgrade to FuseBox 4.1 because our file server is actually separated from our CF servers, so FuseBox can't properly determine the paths to its files. We are working on this in the long term, but for now we are stuck with our operational environment and FuseBox 4.0.

      We have a large government website that has a sitewide CMS, as well as several smaller applications. The goal is that a user signs on from the central management application, and then can navigate the site. This user and their credentials are stored in the Session. Any time a user navigates to a page on the site while logged in, options appear for editing depending on their credentials and the individual application. So essentially we have one main application and several self-contained smaller applications.

      We have recently started upgrading everything to FuseBox. The main application is already upgraded, but now the difficulty lies in the smaller applications. The problem being that we need to maintain one Session throughout the entire site, even when we "switch" to a different application (which is transparent to the end user). However, Fusebox in production mode puts the "fusebox" structure in to the application scope. Meaning that if we have multiple smaller applications in production mode, they all look to application.fusebox for their circuits. This is a problem because obviously the circuits for application A are different for application B, but they all use the same variable and cause errors.

      One solution is to take FuseBox off production mode, but it is far too slow on our server, which is already plagued by unrelated performance issues due to operational configuration that is beyond my power to address.

      Another thing I have tried is putting an application.cfm at the root of each small application, and declaring a new <cfapplication>. That does give me a fresh application scope to put the fusebox in, but unfortunately I lose the Session. I even tried copying the Session variables to a local struct before the <cfapplication> tag then copying them back, but it looks like the first thing that happens is it sees the <cfapplication> tag and starts anew.

      I believe Fusebox 4.1 allows for shared core files, meaning I could put one set of core files at my site root and they could all use the same application.fusebox, but as I mentioned, upgrading to 4.1 is not an option at this point.

      I had also thought about doing some sort of pass-off of the Session through the URL or Form scope, etc., but since users can navigate from any page to a potential application, I have no guaranteed exit mechanism that I can say "ok, they're going to an app so hand off the Session."

      Does anyone know of any way to preserve the Session but switch to a different application scope?

      Thanks in advance for your consideration.
        • 1. Re: Application Scope vs. Session Scope
          BKBK Adobe Community Professional & MVP
          Does anyone know of any way to preserve the Session but switch to a different application scope?
          I think Coldfusion ties a session to a single client and a single application.

          • 2. Re: Application Scope vs. Session Scope
            Sleinaddet Level 1
            Application Session variables can be reset in the Application.cfm file after the scope has been set. For example,

            <CFIF #URL.Number# is '1'>
            <CFSET Application.Color="Red">
            <CFELSEIF #URL.Number# is 2>
            <CFSET Application.Color="Blue">

            Just be careful not to inadvertently reassign a value to "Number" somewhere, otherwise the Application.Color value will change.

            Then #Application.Color# will remain "Red" until you reset it
            • 3. Re: Application Scope vs. Session Scope
              William_At_FAA Level 1
              Thanks all for your replies. However, it's not a matter of resetting the application.fusebox variable as Sleinaddet had suggested. First of all the FuseBox core files handle this functionality, essentially checking to see if application.fusebox is defined. If not, it parses all the circuits found and stores it there. Once it's there, it won't overwrite it.

              Secondly if it did, that just means it would break all the other applications except for the application it just happened to parse, as each application would be looking at the same application.fusebox variable.

              Per BKBK's comment, perhaps it is not possible at this time given my current operational situation. I was hoping someone had discovered a clever workaround or something I had not thought of.
              • 4. Re: Application Scope vs. Session Scope
                BKBK Adobe Community Professional & MVP
                One of my applications uses a UUID as cftoken. In Application.cfc, I set the name of the application to this.name=drumwaves. Here is then some sample output

                session.URLToken: CFID=35020&CFTOKEN=61baffab7264c724-A5C99FFF-B0D2-65DC-E093B4829CE25365

                session.sessionid: DRUMWAVES_35020_61baffab7264c724-A5C99FFF-B0D2-65DC-E093B4829CE25365

                You will see that the ID of the session is linked to the Application's name.

                • 5. Application Scope vs. Session Scope
                  how about using a dbase or cookie to hold the values temporarily? you can transform the entire session scope using cfwddx, store it as text or a LOB or a cookie and then retrieve it after changing applications and just cfwddx it back into the session scope.