13 Replies Latest reply on Mar 6, 2008 12:21 AM by Newsgroup_User

    Why does a feature of CFLOCK seem like a bug?

    <newbie /> Level 1

      I searched this forum for discussions about cflock
      and read the livedocs at http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=sharedVars_20.html.
      This reading is on top of me thinking I already knew
      everything about using the cflock tag.

      Apparently, I am not understanding a very critical
      aspect of the cflock tag when locking the session scope.

      My issue is regarding one user, one session, multiple
      and concurrent requests arriving at the CF8 server
      from the same user session.

      Meaning, a web page that uses ajax, frames, pop-ups,
      or the user hitting ctrl-n, will generate multiple
      requests to the CF8 server using the same session.

      Based on my understanding, using type="exclusive" will
      effectively single-thread the access to code between
      the lock tag. So my question is:


      Why doesn't <cflock scope="session" type="exclusive" ... >
      single-thread the access to the code between the cflock
      tag?


      If you are kind enough to respond, I would really
      appreciate an explanation why the current behavior
      in CF8 is the more correct behavior. If the scope
      is changed from session to application or server, it
      will infact single-thread the access/execution.
      So why is this not the case when the scope is session?

      I arrived at this problem because I was trying
      to explain to someone the difference between:

      <cflock scope="session" type="exclusive" ... >
      and
      <cflock scope="session" type="readOnly" ... >


      Based on my simple test and what I'm seeing, I discovered
      I myself don't know the difference!


      I know how to re-write the code to do exactly
      what I want to do. I just can't seem to wrap
      my head around why the cflock tag is implemented
      this way (with respect to session and exclusivity).

      However, it is more likely that I have a bug in my
      simple test code...?

      If you're interested, here's the code I used to
      confirm/test my assumption:


      Thank you for reading this post to the end!
        • 1. Re: Why does a feature of CFLOCK seem like a bug?
          Grizzly9279 Level 1
          It is my understanding that an exclusive scope lock will simply force other readOnly locks (of the same scope) to wait until the exclusive lock is done doing whatever it is that it is doing. (this prevents "dirty" reads) And I believe it only really impacts code/operations that are specifically referencing memory locations in that scope. If you happen to have other code within the lock that has nothing to do with the scope, it may not single-thread itself at all.

          If you really want to single-thread a block of code, the best way to accomplish that is with a named lock. I do not believe scope locks are intended to do that.

          I hope this helps!


          • 2. Re: Why does a feature of CFLOCK seem like a bug?
            <newbie /> Level 1
            Thank you for responding.

            > an exclusive scope lock will simply force other readOnly
            > locks (of the same scope) to wait until the exclusive
            > lock is done

            I too thought this might be the case. I believe this is a
            more correct behavior. But it appears that we are both
            wrong. The readOnly is not forced to wait until the
            exclusive lock is done.


            > I believe it only really impacts code/operations that are
            > specifically referencing memory locations in that scope

            This statement does not appear to be congruent with livedocs
            and the usage examples given in livedocs. Livedocs specifies
            that the tag should be used "Around file manipulation constructs".


            > If you really want to single-thread a block of code, the best
            > way to accomplish that is with a named lock.

            Right. My only issue with this approach is that the lock
            is accross multiple users and/or multiple sessions.
            Whereas I wanted single-threading per user/session.


            Thanks again for responding. Perhaps there might
            actually be a bug with the CFLOCK tag...?

            • 3. Re: Why does a feature of CFLOCK seem like a bug?
              Grizzly9279 Level 1
              I'm really not sure, but if the session scope exclusive lock isn't doing what you would like it to do, you could always created a named lock using the session ids/tokens as dynamic inputs into the lock name.

              Example:
              <cflock name="namedLock1_#session.sessionId#" type="exclusive" timeout="30">
              • 4. Re: Why does a feature of CFLOCK seem like a bug?
                Level 7
                You don't actually say what you're seeing to suggest that it's not working
                to spec. This would be a good place to start for people trying to work out
                if there's an issue.

                I've seen some "interesting" behaviour when running your sample code which
                has given me pause for thought, but I don't see anything to suggest what
                you're seeing.

                but then again I don't know what your evidence is to suggest anything's
                wrong, so it's hard to say.

                --
                Adam
                • 5. Re: Why does a feature of CFLOCK seem like a bug?
                  <newbie /> Level 1

                  Please be sure that I am very grateful that you both
                  are responding to my post. I am having difficulty
                  articulating exactly the issue since it may be a
                  feature of the CFLOCK tag and not a bug.

                  I thank you for being patient.


                  > You don't actually say what you're seeing to
                  > suggest that it's not working to spec.

                  What I'm seeing (with respect to the session scope
                  and exclusivity) is that the CFLOCK tag is not
                  behaving as documented in livedocs.

                  In particular, I'm referring to this statement in
                  livedocs:

                  "Exclusive - Allows single-thread access to the CFML
                  constructs in its body. The tag body can be executed
                  by one request at a time. No other requests can start
                  executing code within the tag while a request has an
                  exclusive lock. ColdFusion issues exclusive locks on
                  a first-come, first-served basis."

                  It occurred to me that it would be somewhat trivial
                  enough to prove this statement as being true. My
                  attached code was the beginnings of my attempt to
                  actually see single-threading at work.

                  However, what I actually observed was that this statement
                  from livedocs is actually false when using scope="session"
                  and type="exclusive".

                  Meaning, it did NOT "single-thread access to the CFML
                  constructs in its body".


                  > I don't see anything to suggest what you're seeing.
                  > ... I don't know what your evidence is to suggest
                  > anything's wrong

                  My attached code is the beginnings of an attempt to
                  gather some evidence. I was attempting to cause the
                  first request/browser to simulate a process that
                  takes 30 seconds. While the first request is performing
                  it's 30 second long process, I caused the second request/
                  browser to simulate a process that takes zero seconds
                  to perform.

                  My expectation was that the second request/browser will
                  not have an opportunity to begin processing since
                  the first request is holding an exclusive lock.

                  What I actually observed was that second request was
                  able to perform/continue without waiting or being blocked.

                  However, when I changed the scope from session to
                  application or server, I finally did observe the second
                  request waiting/being blocked. If I switch the scope back
                  to scope="session", the second request continues without
                  waiting/being blocked.


                  It is really hard for me to believe that there is a bug
                  here. I really do think that someone went out of their
                  way to allow this feature. I just wish I knew the rational
                  behind allowing this feature (and yet NOT documenting this
                  abnormal behavior in livedocs).


                  Thank you again for responding and taking the time to
                  modify and run my sample code (code must be modified
                  to experience the abnormal behavior). I did take note
                  of your mention that you experienced some "interesting"
                  behavior.

                  • 6. Re: Why does a feature of CFLOCK seem like a bug?
                    Level 7
                    Something to add to your tests is something documenting what session is
                    running each request. Your assumption is that opening a new browser
                    window is accessing the same session. That is not guaranteed to be
                    true. It can happen but it may not happen for many different conditions.

                    So I would first make sure the second request did not run in a different
                    session and thus had no allegiance to the session lock being held in the
                    first session.

                    • 7. Re: Why does a feature of CFLOCK seem like a bug?
                      <newbie /> Level 1

                      Thank you for contributing to this thread. Any advice or
                      thoughts you have is greatly appreciated.


                      > Something to add to your tests is something documenting
                      > what session is running each request.

                      I failed to mention that subsequent to my initial posting,
                      I have modified my simple program to do just as you
                      suggested. I have been testing with #session.SessionID# in
                      the code and can confirm that both windows are displaying
                      the same session id.

                      I have also confirmed that the sessionid is not changing when
                      I hit ctrl-f5 (several times each in both browsers).

                      I have also added a counter variable in the session scope
                      to confirm that either browser can increment the counter
                      and that both browsers correctly increments and displays
                      the next value.


                      > So I would first make sure the second request did not run in
                      > a different session

                      I am 100% sure both browsers are using the same session because
                      both browsers display the same sessionid and is able to increment
                      the same session variable.


                      I am now starting to believe that I'm not the only who
                      believes that <cflock scope="session" type="exclusive" ... >
                      SHOULD cause other requests under the same session to
                      be blocked in order to allow "single-thread access to
                      the CFML constructs in its body".

                      However, I'm still holding out hope that there is no bug
                      here and I'm simply not understanding why this abnormal
                      behavior is necessary/desired.

                      Once again, I thank you for your patience and stamina for
                      reading this post to the end.

                      • 8. Re: Why does a feature of CFLOCK seem like a bug?
                        Level 7
                        i have tried to replicate your tests and DO NOT see the behaviour you
                        are seeing.

                        of course, the testing environments may be different...

                        tested in both cfmx 7 and cf8 [installed on same laptop]
                        in ff2 browser (opening new tab instead of new window to ensure session
                        is preserved)
                        both cf servers are set to use J2EE sessions
                        i have added name='cflocktest' in the <cfapplication> tag in your code

                        what i am seeing is:
                        - when the url.work var is defined, the page takes about 300 times
                        longer to load than without that var in url on both systems
                        - the second tab dutifully waits 30 seconds for the first tab to release
                        the lock

                        i will try to test with regular sessions on more browsers later, but
                        somehow i do not think i will see your results...

                        Azadi Saryev
                        Sabai-dee.com
                        http://www.sabai-dee.com/
                        • 9. Re: Why does a feature of CFLOCK seem like a bug?
                          <newbie /> Level 1

                          Thank you so very much for taking the time
                          look into the issue I am having.


                          > of course, the testing environments may be different...

                          I too have tested on CF7 and CF8. For me,
                          the behavior is the same on both environments.

                          However, my previous sample code required some
                          changes before it could be used for testing.

                          I have attached a new sample code that does
                          not require any changes but yet will still
                          illustrate the behavior I have described.

                          Also, here are the ten steps I took to observe
                          the behavior:

                          1) Open a browser and go to http://localhost/test.cfm?work=false
                          2) Hit ctrl-n (to open second browser)
                          3) Confirm that both browsers display the same session id
                          4) Hit ctrl-f5 a few times while alternating browsers
                          5) Confirm that session id is not changing and counter is incrementing
                          6) Note the counter values in browser one and browser two
                          7) In browser one, change the url param from work=false to work=true
                          and hit the Enter key
                          8) In browser two hit ctrl-f5 once and notice that it returns right away
                          9) Hit ctrl-f5 in browser two a few more times and watch the counter go up
                          10) In browser one, wait for page to return and notice the counter value


                          For my particular run of the test, at step 6,
                          browser one had a counter value of eight and
                          browser two had a counter value of five.

                          By step 10, my browser one's counter value
                          was now fifteen.

                          How could the counter have go up from 8 to 15
                          if browser one had an exclusive lock?

                          In other words, why does step 8 and step 9
                          return right away with an incremented counter
                          value if in step 7 browser one obtained an
                          exclusive lock?


                          Here's the new sample code. Save it as test.cfm.

                          You do not have to make any modifications.

                          I am glad to hear that you are not experiencing what
                          I have observed. Perhaps this new sample code
                          and test script can serve as a baseline for others
                          who want to participate.

                          Thank you again for your efforts.
                          • 10. Re: Why does a feature of CFLOCK seem like a bug?
                            Level 7
                            i have tried your new code, and in both cf7 and cf8, and both with
                            second page in new tab and new window, i got a lock timeout errors on
                            page 2...

                            Azadi Saryev
                            Sabai-dee.com
                            http://www.sabai-dee.com/
                            • 11. Re: Why does a feature of CFLOCK seem like a bug?
                              <newbie /> Level 1

                              Thank you all for giving this topic consideration.

                              Alas the answer was due to my bad code.

                              Azadi's hint and persistence paid off.

                              The issue was due to my <cfapplication> tag NOT
                              having the REQUIRED attribute "NAME".

                              I was able to observe the desired behavior by
                              simply changing my new sample code to include
                              the name attribute in my <cfapplication> tag.


                              Thank you again to all who gave this post some
                              careful thought.


                              By the way, in CF5, the name attribute is a required
                              attribute. Post CF5 it is optional. After going
                              through six different environments with six different
                              configurations, I found a CF5 CD and installed it.

                              After removing the java-ish code, I promptly got
                              an error stating that the name attribute is a required
                              attribute... ouch.


                              Perhaps someone from Adobe's ColdFusion team
                              can make a change such that if the tag validator sees
                              this line of code...

                              <cfapplication sessionmanagement="true" />

                              the tag validator will throw an error stating that
                              the NAME attribute is missing.

                              Perhaps I should have titled this topic as:

                              Why does a feature of cfapplication seem like a bug?
                              when sessionmanagement=true and name attribute is missing

                              • 12. Re: Why does a feature of CFLOCK seem like a bug?
                                Level 7
                                yes, i knew it would be that! :)

                                Azadi Saryev
                                Sabai-dee.com
                                http://www.sabai-dee.com/
                                • 13. Re: Why does a feature of CFLOCK seem like a bug?
                                  Level 7
                                  > Why does a feature of cfapplication seem like a bug?
                                  > when sessionmanagement=true and name attribute is missing

                                  Well it *is* documented as being required if one wishes to use session
                                  variables: http://livedocs.adobe.com/coldfusion/8/Tags_a-b_5.html

                                  That said, it would be nice if having the sessionmanagement attribute
                                  without a name attribute caused an error.

                                  Now: for my strange behaviour.

                                  When *I* run your code (or a variation in which it's easier to see what's
                                  going on and when) on Firefox, Firefox seems single-threads the requests
                                  completely, ie: the first line of code (which in my version outputs a
                                  timestamp) of request 2 does not execute until after request 1 completely
                                  finishes. Not so if I run both browser sessions in IE, or - predictably -
                                  a mix of the two.

                                  If I run the test in Opera, then both windows *output exactly the same
                                  results* (including timestamps!), despite the processes clearly being
                                  kicked off at different times, due to me not being able to instantaneously
                                  kick of each request in two different windows.

                                  Although I put this down to screwiness on my PC.

                                  --
                                  Adam