I apologize in advance if this has already been hashed and rehashed...

In the Web Application Construction Kit for CFMX, it says:

"Previous versions of CF required you to use locks far more frequently,
even when there wasn't a race condition issue at hand. Basically, you
needed to lock every line of code that used application or session
variables. This is no longer the case. Beginning in CFMX, you need only
lock application or session variables if you are concerned about race
condition issues."

I take that to mean that a line like the following should be locked:

<CFSET APPLICATION.CounterThatMustBeAccurate =
APPLICATION.CounterThatMustBeAccurate + 1>

The possible loss of correctness resulting from a race condition is obvious
in that situation.

In the CFMX Bible, on pg. 469, it says:

"Because you no longer need to worry about data corruption in shared-memory
scopes, you now must concern yourself only with preventing race condtions,
where two pieces of code attempt to access the same shared-memory variables
at the same moment."

That appears to agree with the first quote from WACK, but I'm confused by
other statements such as on page 473 where it says:

"If (This.SomeVar) can ever be rewritten, even with the same value that it
already contained, you would need to lock it on every read. The decision to
lock is based on whether the variable is written to memory only once or
multiple times during its scope's life cycle and not whether its value
changes from one writing to the next."

Is that statement correct? According to that statement, if you assigned a
constant string to an application variable within your application.cfm, you
would need an exclusive lock around the write and a readonly lock around
any reads.

in application.cfm:
<CFSET APPLICATION.SomeSetting = "SomeConstantValue">

in page.cfm:
<CFOUTPUT>#APPLICATION.SomeSetting#</CFOUTPUT>

Is there a race condition possibility in that situation? If so, the
negative effect is much less apparent than in the first example where
you're incrementing a counter. Is that write not an atomic action? Assuming
no locks were used, under a heavy enough load for race conditions to become
a factor, what kind of errors would be caused--memory leaks/bizarre server
errors? Partial or garbage values read for APPLICATION.SomeSetting?

So, my question is, when do I need to lock in CFMX. Is it...

A) Only where a race condition could lead to a logically incorrect result,
as in the counter incrementing example.

OR

B) For ALL writes and reads of persistent scoped variables, except for
those that are only written once and then never rewritten.

Thanks!

Conan
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]

Reply via email to