Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Shaun E on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Locking application and session variables

Status
Not open for further replies.

jianhua

Programmer
Jun 22, 2001
55
US
Hi,

Do I need to lock every <cfquery> if the query's datasourse is #application.ds# and there is a session variable within the query such as where job_id = #session.job_id#?

The code would be:

<cflock scope=&quot;application&quot; type=&quot;readonly&quot; timeout=&quot;10&quot;>
<cflock scope=&quot;session&quot; type=&quot;readonly&quot;(or EXCLUSIVE depends on the query) timeout=&quot;10&quot;>
<cfquery name=&quot;queryname&quot; datasource=&quot;#application.ds#&quot;>
Select or Update or Insert or Delete ...
...
</cfquery>
</cflock>
</cflock>

Thanks,
J
 
Technically, yes; the more complicated answer is that there may be a better way to do it.

Any code block that references a variable in Application or Session scope must be locked in exclusive mode if the variable is or may be created or changed, or in readonly mode otherwise. Remember that certain tags and expressions, such as <CFPARAM>, always need to be locked exclusively because they may write to the variable in question.

There are many common ways to make your life easier when it comes to locking. For variables that will be referenced multiple times over the course of the request but will not change (like variables for your datasource, database username/password, etc.), it is common to copy the variables from the Session or Application scope into the Request scope at the beginning of the request (perhaps in the Application.cfm page). Variables in the Request scope are available to every page in the request, including <CFINCLUDE>s and custom tags, but the Request scope is not a shared scope and need not be locked.

For variables that must be referenced from the shared scope, it is considered a best practice to keep a lock open only long enough to copy the variable into some non-shared scope. It is considered a Very Bad Thing to execute a potentially time-consuming block of code (such as a database query, file operation, <CFHTTP> call, etc.) inside a lock.
 
Yes, you should lock all occurrences. The best way to accomplish this without generating spaghetti code is to lock the scope that contains the variable(s) you want to use first, copy them into a local variable (or request variable if you are using custom tags that need to be able to access the variable) and use the local or request variable in your quer(ies)y:
Code:
<cflock scope=&quot;application&quot; type=&quot;readonly&quot; timeout=&quot;10&quot;>
<cfset request.ds = application.ds>
</cflock>

<cfquery datasource=&quot;#request.ds#&quot; name=&quot;myquery&quot;>
...SQL...
</cfquery>
To avoid locking the Application scope altogether, set your datasource in application.cfm like so:
Code:
<cfset request.ds = &quot;mydatasource&quot;>
Then on every page you will have a global variable (meaning global to the page request and any custom tags within that request) to use as your datasource, without needing to lock it.

-Tek
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top