15 Replies Latest reply on Jul 11, 2006 5:25 AM by BKBK

    cflock session - named or not?

    Bugsville
      I juts went through a bunch of apps and cflocked the heck out of lots of session variables being set. This greatly improved my server problems. However, I locked these all with a Name and not the Scope

      Now my server is getting quirky again and I want to see if this is my issue.

      I ahve read contradictory thinsg online about whether a session variable should be set as scope="session" or given a unique name.

      So which is best?
        • 1. Re: cflock session - named or not?
          Level 7
          All locked code with the same scope OR name share the same cue and
          timeout no matter where they are running from. You can use this to your
          advantage.

          If you want several locks running in different places in the code to
          never run at the same time not matter how many threads are running any
          of this code, give these locks the same name or scope.

          But do too much of this, you will have very long cues of processes
          lining up and waiting for their turn to run the code inside the given lock.

          Bugsville wrote:
          > I juts went through a bunch of apps and cflocked the heck out of lots of
          > session variables being set. This greatly improved my server problems. However,
          > I locked these all with a Name and not the Scope
          >
          > Now my server is getting quirky again and I want to see if this is my issue.
          >
          > I ahve read contradictory thinsg online about whether a session variable
          > should be set as scope="session" or given a unique name.
          >
          > So which is best?
          >
          • 2. Re: cflock session - named or not?
            pete_freitag Adobe Community Professional
            If your using version 6.0 or greater you don't even need to use cflock in most cases
            • 3. Re: cflock session - named or not?
              Level 7
              Also if you have given every lock a unique name, but these locks are
              runs the same code, you have not locked the code.

              Example:

              <cflock ... name="foo">
              <cfset session.myVar = "george">
              </cflock>

              And someplace else:

              <cflock ... name="bar">
              <cfset session.myVar = "fred">
              </cflock>

              Both of these cfsets can run at the same time, and if this was causing a
              problem before the locks, they will still be a problem after the locks.
              In this case you would probably want to use the same name or scope.

              Now more recent versions of ColdFusion are much better at protection run
              conditions in shared scoped variables. So you should not necessarily
              need to cope every last instance of them, depending on what you are doing.

              Bugsville wrote:
              > I juts went through a bunch of apps and cflocked the heck out of lots of
              > session variables being set. This greatly improved my server problems. However,
              > I locked these all with a Name and not the Scope
              >
              > Now my server is getting quirky again and I want to see if this is my issue.
              >
              > I ahve read contradictory thinsg online about whether a session variable
              > should be set as scope="session" or given a unique name.
              >
              > So which is best?
              >
              • 4. cflock session - named or not?
                BKBK Adobe Community Professional & MVP
                There are situations where it is necessary to lock session code. A common example is when a shared variable is updated, as happens in

                <cflock scope="SESSION" timeout="3" type="EXCLUSIVE">
                <cfset session.clientBalance = session.clientBalance - 99.50>
                </cflock>

                Therefore, choosing in general not to use locks is not a wise option. It all depends on the code.

                • 5. Re: cflock session - named or not?
                  Level 7
                  > There are situations where it is necessary to lock session code. A common
                  > example is when a shared variable is updated, as happens in
                  >
                  > <cflock scope="SESSION" timeout="3" type="READONLY">
                  > <cfset session.clientBalance = session.clientBalance - 99.50>
                  > </cflock>
                  >
                  > Therefore, choosing in general not to use locks is not a wise option. It all
                  > depends on the code.

                  This has not been necessary since CF5. You do NOT have to lock simple
                  <cfset> expressions like this.

                  Even in CF5 this example is wrong, because you're setting the variable it
                  should be an exclusive lock.

                  The only time you need to lock code these days is to prevent race
                  conditions.

                  --
                  Adam
                  • 6. Re: cflock session - named or not?
                    BKBK Adobe Community Professional & MVP
                    A transmission delay of the system, you will have noticed. Apparently, you, newsgroup users, don't receive corrections. The "Readonly" was simply the result of clicking too quick on the automatic tag completor. I had it corrected to "Exclusive" within seconds of posting, one day before already.

                    > This has not been necessary since CF5. You do NOT have to lock simple
                    > <cfset> expressions like this.
                    [<cfset session.clientBalance = session.clientBalance - 99.50>]
                    > The only time you need to lock code these days is to prevent race
                    > conditions.


                    The "simple" <cfset> expression, <cfset session.clientBalance = session.clientBalance - 99.50>, is actually an example of code that can result in a race condition. It therefore requires a lock.



                    • 7. Re: cflock session - named or not?
                      Level 7
                      > A transmission delay of the system, you will have noticed. Apparently, you,
                      > newsgroup users, don't receive corrections.

                      It would seem not. This could be due to articles only going to the NNTP
                      gateway once, or that once my reader gets an article, it does "re-get" it
                      if someone updates it. Not sure.


                      > The "simple" <cfset> expression, <cfset session.clientBalance =
                      > session.clientBalance - 99.50>
                      , is actually an example of code that can
                      > result in a race condition. It therefore requires a lock.

                      My initial response to that is "no, actually: it's not". However I'm
                      always open minded (-ish). Can you pls explain how it is a race condition?

                      --
                      Adam
                      • 8. Re: cflock session - named or not?
                        BKBK Adobe Community Professional & MVP
                        Assume the current value of session.clientBalance is 300. It is conceivable that two separate requests from the same session could simultaneously reach the line

                        <cfset session.clientBalance = session.clientBalance - 99.50>

                        The result would be:

                        session.clientBalance after Request 1: 200.50
                        session.clientBalance after Request 2: 200.50

                        That scenario would never occur when the exclusive lock is used. The client balance would then be 200.50 after one request, and 101 after the next.

                        • 9. Re: cflock session - named or not?
                          Level 7
                          > Assume the current value of session.clientBalance is 300. It is conceivable
                          > that two separate requests from the same session could simultaneously reach the
                          > line
                          >
                          > <cfset session.clientBalance = session.clientBalance - 99.50>
                          >
                          > The result would be:
                          >
                          > session.clientBalance after Request 1: 200.50
                          > session.clientBalance after Request 2: 200.50
                          >
                          > That scenario would never occur when the exclusive lock is used. The client
                          > balance would then be 200.50 after one request, and 101 after the next.

                          This would have been true in CF5. As per what Pete alluded to earlier, it
                          has not been the case since CF6. Java automatically locks this sort of
                          situation. The only race conditions that one needs to be worried about is
                          where it is essential that nothing changes the value of a variable BETWEEN
                          TWO statements being executed, eg:

                          <cfparam name="session.inited" default="false">
                          <cfif not session.inited>
                          <!--- do some stuff that you don't want run unless session.inited is false
                          --->
                          <cfset session.inited = true>
                          </cfif>

                          So it's possible for one thread to hit the first line, and start initing
                          the session. And before that thread gets to the <cfset>, another thread
                          could hit the <cfif>, and commence the session-init code a second time.

                          THAT'S the situation you need to lock.

                          --
                          Adam
                          • 10. Re: cflock session - named or not?
                            BKBK Adobe Community Professional & MVP
                            > This would have been true in CF5. As per what Pete alluded to earlier, it
                            > has not been the case since CF6. Java automatically locks this sort of
                            > situation.

                            May be so, but it's not yet an exact science. You apparently presume that the line <cfset session.clientBalance = session.clientBalance - 99.50> exists in isolation. That is almost never the case in practice. There is usually other code in the way, often involved, some of it also in session scope. In fact, the relative delays here and speed-ups there are the main determinants of the race conditions between two request threads contending for the session code-block.

                            I've attempted to simulate an example.

                            1) Right-click on link 1 and Open in New Window. That begins the first request.
                            2) Immediately right-click on link 2 and Open in New Window.

                            The requests might represent transactions. Without the lock, the second request will run first. With a lock, the second request will always wait till the first finishes, which is what most account-updating code want.


                            • 11. Re: cflock session - named or not?
                              Level 7
                              Well... *precisely*. You're demonstrating *my* point, not yours.

                              You cited this example:

                              <cflock scope="SESSION" timeout="3" type="READONLY">
                              <cfset session.clientBalance = session.clientBalance - 99.50>
                              </cflock>


                              There is no need to lock this. CF code is automatically locked @ statement
                              level, so that ONE line of code cannot be *simultaneously* accessed by two
                              threads.

                              What Might happen in CF5 is that two threads could hit that line of code at
                              exactly the same time, and increment the SAME session.clientBalance value
                              twice (meaning one increment is lost). That's bad. And accordingly you
                              needed to lock the code so each thread would hit the code in turn.

                              However this cannot happen in CFMX. Java forces one of the threads to wait
                              until the other finishes, and THEN the second thread runs that statement
                              (so two increments, one for each thread: correct).

                              What your demonstrating with your example is that race conditions can arise
                              within a code BLOCK (my assertion), not a single STATEMENT (your assertion,
                              which I was correcting).

                              So... yes. We're in agreement. :-)

                              --
                              Adam
                              • 12. Re: cflock session - named or not?
                                Oh. That's just a terrible explanation, sorry, I was in a rush to get to the pub (or at least t my mate's place to drink beer, where - sadly - I am now, on the computer). It's not controlled @ CF-statement-level at all.

                                Basically, the session scope is "synchronised" at a Java level: each operation on the session scope is queued, so it's impossible for two operations to take place at once. Hence not needing to lock individual CF statements.

                                But, yes, this does not help race conditions that crop up across code blocks (as per both our examples).

                                The crux of this is that telling someone they need to lock a single <cfset> because it deals with the session scope is outright wrong, post-CF5.

                                --
                                Adam
                                • 13. cflock session - named or not?
                                  BKBK Adobe Community Professional & MVP
                                  > Well... *precisely*. You're demonstrating *my* point, not yours.

                                  > You cited this example:

                                  > <cflock scope="SESSION" timeout="3" type="READONLY">
                                  > <cfset session.clientBalance = session.clientBalance - 99.50>
                                  > </cflock>


                                  No need to waste time there. I corrected it two days ago.

                                  > There is no need to lock this. CF code is automatically locked @ statement
                                  > level, so that ONE line of code cannot be *simultaneously* accessed by two
                                  > threads.

                                  > What Might happen in CF5 is that two threads could hit that line of code at
                                  > exactly the same time, and increment the SAME session.clientBalance value
                                  > twice (meaning one increment is lost). That's bad. And accordingly you
                                  > needed to lock the code so each thread would hit the code in turn.

                                  > However this cannot happen in CFMX. Java forces one of the threads to wait
                                  > until the other finishes, and THEN the second thread runs that statement
                                  > (so two increments, one for each thread: correct).
                                  ...
                                  > Basically, the session scope is "synchronised" at a Java level: each
                                  > operation on the session scope is queued, so it's impossible for two
                                  > operations to take place at once. Hence not needing to lock individual
                                  > CF statements.


                                  I suppose what you mean is that, since version MX, Coldfusion is thread-safe. Two threads will therefore not modify a variable at the same time. As I said before, that is not an exact science. Thread-safety is complicated by technical matters as atomicity and reentrancy. Note in particular that <cfset session.clientBalance = session.clientBalance - 99.50> is a recursive statement.

                                  > The crux of this is that telling someone they need to lock a single <cfset>
                                  > because it deals with the session scope is outright wrong, post-CF5.


                                  This MX7 livedocs on locking explains how and why to lock a single cfset.



                                  • 14. Re: cflock session - named or not?
                                    Level 7
                                    > > You cited this example:
                                    >
                                    > > <cflock scope="SESSION" timeout="3" type="READONLY">
                                    > > <cfset session.clientBalance = session.clientBalance - 99.50>
                                    > > </cflock>
                                    >
                                    > No need to waste time there. I corrected it two days ago.

                                    No you didn't. You changed the lock to EXCLUSIVE. The fact that the lock
                                    is there *at all* is what's incorrect.


                                    > I suppose what you mean is that, since version MX, Coldfusion is thread-safe.
                                    > Two threads will therefore not modify a variable at the same time. As I said
                                    > before, that is not an exact science.

                                    Yeah. It is. Well so close to one that when one is operating at the CF
                                    level of things, it might as well be.


                                    > Thread-safety is complicated by technical
                                    > matters as atomicity and reentrancy. Note in particular that <cfset
                                    > session.clientBalance = session.clientBalance - 99.50> is a recursive statement.

                                    [snort]

                                    Nice sentence. Nice use of buzzwords. It doesn't *mean* anything though,
                                    does it?


                                    > This http://livedocs.macromedia.com/coldfusion/7/htmldocs/00001167.htm
                                    > explains how and why to a single cfset.

                                    The top section of that guidance is wrong. But fair enough if that's what
                                    you were running with: one *should* be able to trust the docs.

                                    The bit starting with "Ensuring consistency of multiple variables" is
                                    correct, though.

                                    I will pursue a correction for the top bit.

                                    --
                                    Adam
                                    • 15. cflock session - named or not?
                                      BKBK Adobe Community Professional & MVP
                                      > No you didn't. You changed the lock to EXCLUSIVE.
                                      I only meant that you should not have repeated
                                      the READONLY, two days after it is corrected. Its
                                      presence confuses what follows.

                                      > The fact that the lock is there *at all* is what's incorrect.
                                      Can you see the absurdity in suggesting that the following code is
                                      incorrect because it contains a lock?
                                      <cflock scope="SESSION" timeout="3" type="EXCLUSIVE">
                                      <cfset session.clientBalance = session.clientBalance - 99.50>
                                      </cflock>


                                      > [snort]
                                      > Nice sentence. Nice use of buzzwords [atomicity, reentrancy, recursion].
                                      > It doesn't *mean* anything though, does it?

                                      Funnily enough, you've answered that question yourself. At least, partly. You write, a little later, "The bit starting with "Ensuring consistency of multiple variables" is correct, though." Well, that bit contains a word that is so important it is the only one highlighted in bold. It is the word atomic.

                                      Recursive updating of a variable is good for thread-safety, however, not when it is a shared variable. The processor might decide to update its value in two or more steps (non-atomicity). If, Thread A is interrupted while it is updating the variable session.clientBalance, and Thread B updates the variable, will the value be consistent after Thread A resumes and finishes (reentrancy)? Those are issues that affect thread-safety. It is sufficient that some questions are raised.

                                      None of them arises when you use a lock. Here, Java can speak for Coldfusion. Synchronization ensures that Thread A's update will be visible to Thread B. However, the only way to ensure consistency is for the synchronized code blocks to hold the same lock object. The general advice in the literature, for synchronized Java code as well as for Coldfusion, is to always use a lock (for often-updated shared variables) if the application is mission-critical. Think of code to update a bank account or code to dispense the drips going into a patient.