On 4/14/07, Andrew Scott <[EMAIL PROTECTED]> wrote:
> Thats what I mean, best practice says use cfqueryparam, and every document
> you read regardless of cfmx 5.0, 6.0, 7.0 says when writing to a variable
> you will have a race condition.
No. It is *not* the case that you "will" have a race condition. It is
possible that your code may be such that a race condition is
*possible*.
For example, this line alone cannot possibly cause a race condition:
<cfset application.flag = true />
However, depending on how your code uses that variable, your code may
create the possibility of a race condition and need locking.
A traditional example is:
<cfif not structKeyExists(application,"initialized") or not
application.initialized>
... do a bunch of initialization ...
<cfset application.initialized = true />
</cfif>
This is prone to race conditions because two request can enter the
"bunch" code simultaneously. The correct solution here is to lock (on
a named lock) *and* to double-check the condition:
<cfif not structKeyExists(application,"initialized") or not
application.initialized>
<cflock name="#application.applicationName#_initialization"
type="exclusive" timeout="30">
<cfif not structKeyExists(application,"initialized") or not
application.initialized>
... do a bunch of initialization ...
<cfset application.initialized = true />
</cfif>
</cflock>
</cfif>
However, if the "bunch" code itself is not affected by the race
condition - e.g., all assignments are simple values with no
dependencies and no other application code would be affected by them
being reset sequentially - then you wouldn't need to lock.
The following is also prone to race conditions if a single user can
make multiple simultaneous requests:
<cfset session.count = session.count + 1 />
However, it may not matter that you get a race condition here and if
it doesn't matter, you don't need to lock.
> Now I can't name the version I tested this on, but I followed one of the
> articles directions on how a race condition will work. And you know what, it
> proves that even this version of Coldfusion needs cflock around perstant
> variable writes.
They're not "persistent" variables (memory is not persistent). They
are "shared" variables. And just because a race condition is possible
in *some* code does not "prove" that you need cflock around all shared
variable writes.
In some cases, in some code, you might need to lock.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Deploy Web Applications Quickly across the enterprise with ColdFusion MX7 &
Flex 2
Free Trial
http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJU
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:275256
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
