8 Replies Latest reply on Jun 27, 2006 1:14 PM by Newsgroup_User

    CFLOCK around isDefined statment?

    pdmackay Level 1
      Hi,
      Is it necessary to put a cflock tag around an isDefined check? I was not going to do that but add a cflock to withing the if satement where the variable is actually set. Here is the code I'm working with:

      <cfif not isDefined("application.orderType")>
      <cfquery name="application.orderType" datasource="#datasource#">
      SELECT * FROM oew_orderType ORDER BY orderType
      </cfquery>
      </cfif>
        • 1. Re: CFLOCK around isDefined statment?
          Level 7
          You should do it when you set the variable.

          --
          Ken Ford
          Adobe Community Expert


          "pdmackay" <webforumsuser@macromedia.com> wrote in message
          news:e7ppe7$l2l$1@forums.macromedia.com...
          > Hi,
          > Is it necessary to put a cflock tag around an isDefined check? I was not
          > going to do that but add a cflock to withing the if satement where the
          > variable
          > is actually set. Here is the code I'm working with:
          >
          > <cfif not isDefined("application.orderType")>
          > <cfquery name="application.orderType" datasource="#datasource#">
          > SELECT * FROM oew_orderType ORDER BY orderType
          > </cfquery>
          > </cfif>
          >


          • 2. Re: CFLOCK around isDefined statment?
            Dan Bracuk Level 5
            no it is not necessary to use cflock when you use isdefined.

            Also, using an application variable as a query name probably won't work.
            • 3. Re: CFLOCK around isDefined statment?
              Level 7
              > Also, using an application variable as a query name probably won't work.

              Why do you say that?

              --
              Adam
              • 4. Re: CFLOCK around isDefined statment?
                Iceborer
                > Also, using an application variable as a query name probably won't work.

                Ugh, I'm going to have to change some production code, then. :)
                • 5. Re: CFLOCK around isDefined statment?
                  pdmackay Level 1
                  Thanks for the insight. Now I can just wrap the query with the cflock or after it is run set it. Naming the query as an application variable has been working fine for me (mx 7).
                  • 6. Re: CFLOCK around isDefined statment?
                    Level 7
                    >> Also, using an application variable as a query name probably won't work.
                    >
                    > Ugh, I'm going to have to change some production code, then. :)

                    Don't go charging off changing code just yet: there's nothing synactically
                    incorrect with using an application-scoped variable as the name of a query.
                    I'm just wondering what Dan was actually thinking when he made that (above)
                    statement.

                    That said, I'd perhaps do this:

                    <cfif not structKeyExists(application, "orderType")>
                    <cfquery name=variables.orderType" datasource="#datasource#">
                    SELECT SPECIFY_YOUR_COLUMN_LIST_HERE
                    FROM oew_orderType
                    ORDER BY orderType
                    </cfquery>
                    <cfset application.orderType = variables.orderType>
                    </cfif>

                    Doing this means you don't have to have any <cflocks> at all, as Java
                    automatically locks variables whilst a CF statement is accessing them. If
                    you were setting it straight with the <cfquery>, I probably WOULD err
                    towards locking it, which is going to be a performance hit.

                    Also don't do SELECT *. It's just lazy.

                    --
                    Adam
                    • 7. Re: CFLOCK around isDefined statment?
                      pdmackay Level 1
                      No cflock needed at all if within a cfif statement? Cool. Yep, most times I like to put the columns in my select statement however the table only has orderType and orderTypeId so I let that go. I'll think about that.

                      How about using a cfparam?
                      Do I need to surround this cfparam with a cflock? Right now I am.

                      <cfparam name="SESSION.IsAuthenticated" default="FALSE">
                      • 8. Re: CFLOCK around isDefined statment?
                        Level 7
                        > How about using a cfparam?
                        > Do I need to surround this cfparam with a cflock? Right now I am.
                        >
                        > <cfparam name="SESSION.IsAuthenticated" default="FALSE">

                        Nope.

                        Since CF moved to Java (6.0), the only time one needs to lock variable
                        setting activity is when there's a chance of a "race condition", eg:

                        <cfif not structKeyExists(session, "foo")>
                        <!--- here starts a bunch of code you REALLY don't want to run any more
                        than ONCE, immediately prior to setting session.foo --->
                        <!--- lines of code --->
                        <!--- end of all that processing --->
                        <cfset session.foo = someValueContingentOnTheAboveCode>
                        </cfif>

                        If you don't lock that code block, a second process COULD start executing
                        it before a preceding process gets to the bottom and sets session.foo.

                        If it's simply a single statement(*): there's *no need* to lock it, because
                        Java automatically locks an variables in the statement it's currently
                        processing.

                        (*) "single statement" is perhaps a misnomer, because I WOULD lock this:

                        <cfset session.foo = myFunctionWithManyStatementsInIt()>

                        For the above reasons (potential undesirable race conditions in the
                        function code).

                        --
                        Adam