know I'm not Ben Forta, but it's been something I've been meaning to do for
a while, and this was the impetus that finally made it happen.
http://www.barneyb.com/blog/archives/2004_03.shtml#000069
Cheers,
barneyb
> -----Original Message-----
> From: Conan Saunders [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 10, 2004 1:09 AM
> To: CF-Talk
> Subject: YALT: when to lock in CFMX
>
> 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]
