6 Replies Latest reply on Nov 7, 2008 7:40 AM by Newsgroup_User

    cflock and accessing session and application variables

    jqcf Level 1
      Is the information in this article still pertinent with Coldfusion 8?
      http://www.adobe.com/devnet/server_archive/articles/cf_locking_best_practices.html
        • 1. Re: cflock and accessing session and application variables
          Level 7
          jqcf wrote:
          > Is the information in this article still pertinent with Coldfusion 8?
          > http://www.adobe.com/devnet/server_archive/articles/cf_locking_best_practices.html

          My understanding is that ALWAYS locking is now out-of-date advice.
          There where bugs that caused performance issues if one did not lock
          everything back in the 4.x days. But I have read that this has been
          long resolved.

          So the advice I advocate is to intelligently lock, when the application
          logic requires it. I.E. Lock when there is a race condition and that
          race condition can cause improper program execution.

          The reason to not just lock everything, every time is that there can be
          severe performance consequences to doing this. That article does give
          some good advice on this to minimize the consequences. But why restrict
          an application in such a way if it is unnecessary.
          • 2. Re: cflock and accessing session and application variables
            Kling Level 1
            Hi all,
            My boss wants to find out if our Coding Standards are out of date... they call for CFLOCKS for all calls of Session variables (EXCLUSIVE for cfsets, READONLY for anywhere one is referenced). Allaire (remember them?) recommended this a decade ago and we never updated it.
            • 3. Re: cflock and accessing session and application   variables
              Level 7
              Yup, that was advice that applied to the 4.x - Allaire versions of CF.
              This standard is two companies and four versions (I don't know how many
              updaters and hotfixes) out of date.

              There are real performance and scalability issues to over use of
              <cflock...> tags. The reason for doing so no longer apply. So I would
              recommend updating your standard to only using <cflock...> when
              requirements or logic require it.
              • 4. Re: cflock and accessing session and application variables
                Kling Level 1
                Thanks!
                But could you be more specific on "when requirements or logic" will require it? It would be really cool if you could point to something official from Adobe (I searched and couldn't find anything)
                • 5. Re: cflock and accessing session and application   variables
                  Level 7
                  in a nutshell, you need to lock a scope if there is a possibility of a
                  "race condition" - when more than one request may attempt to modify the
                  variable(s) in question at the same time.
                  IF and WHEN this race condition may occur depends on your application logic.
                  as a rule, WRITING to a shared scope should be locked, just to avoid any
                  possibility of a race condition...


                  Azadi Saryev
                  Sabai-dee.com
                  http://www.sabai-dee.com/
                  • 6. Re: cflock and accessing session and application   variables
                    Level 7
                    Kling wrote:
                    > Thanks!
                    > But could you be more specific on "when requirements or logic" will require
                    > it? It would be really cool if you could point to something official from Adobe
                    > (I searched and couldn't find anything)
                    >

                    As Azadi said in his reply, the requirements would be when there is a
                    need to be concerned about "race conditions". This is a standard
                    computer science 201 programming logic concept and applies to all
                    languages, so Adobe doesn't really have anything 'official' to say about it.

                    The reason that back in the day, Allaire had this strong recommendation
                    was that there was an identified bug in the CF 4.x version where
                    unlocked, multiple thread reading and writing of shared scope variables
                    could cause memory leaks that would eventually destabilize the server.
                    This bug has been addressed as of version 5 so this is no longer a concern.

                    So now you only need to be concerned with your data and how multiple
                    users interacting with that data can affect your application. If there
                    is a concern where user A can change a shared variable and before user A
                    can use the proper value user B can change the value and this makes for
                    incorrect results; then you have a race condition and <cflock...> may be
                    appropriate.

                    A secondary use of the <cflock...> tag can be where you just want a
                    piece of code to be single threaded. I.E. a block of code should only
                    be run for a single user at any given moment. This is usually for
                    accessing some external resource that is not multi-thread safe.

                    Just be aware that this single-threading aspect of the use of the
                    <cflock...> tag can have an impact on the throughput and scalability of
                    your code. Too much of it on too large blocks of code can cause user
                    requests to start to pile up while each request waits its turn to run
                    through the locked block of code.