• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

CFLOCK around isDefined statment?

New Here ,
Jun 26, 2006 Jun 26, 2006

Copy link to clipboard

Copied

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>
TOPICS
Advanced techniques

Views

836

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Jun 26, 2006 Jun 26, 2006

Copy link to clipboard

Copied

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>
>


Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Jun 26, 2006 Jun 26, 2006

Copy link to clipboard

Copied

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Jun 26, 2006 Jun 26, 2006

Copy link to clipboard

Copied

> Also, using an application variable as a query name probably won't work.

Why do you say that?

--
Adam

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Participant ,
Jun 27, 2006 Jun 27, 2006

Copy link to clipboard

Copied

> 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. :)

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jun 27, 2006 Jun 27, 2006

Copy link to clipboard

Copied

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).

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Jun 27, 2006 Jun 27, 2006

Copy link to clipboard

Copied

>> 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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jun 27, 2006 Jun 27, 2006

Copy link to clipboard

Copied

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">

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
LEGEND ,
Jun 27, 2006 Jun 27, 2006

Copy link to clipboard

Copied

LATEST
> 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

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation