When Macromedia released CFMX6.1 (RedSky) after months of solid development
and testing by (many) beta users (myself included) 6.1 was unleashed upon
the world.
RedSky is the fastest and most scalable version of CF yet. MM built upon
their efforts with Neo (6.0) to produce the fastest ColdFusion ever. With
Blackstone it looks to only get better.
Of course with something so fast and scalable issues like "race conditions"
cannot be ignored.
I think it comes down to either common sense or a lot of "load testing" to
determine when to lock and when not to.
Because CF is built on J2EE technology perhaps locking isn't the issue it
was with previous versions.
With your counter example I would lock it as you mention
"CounterThatMustBeAccurate". Reading from Application/Session possibly would
not be an issue as long as you use CFLOCK when setting or changing a
variable in this scope.
Personally I'd love to see a locking "expert" like Ben Forta write an
article to clear these issues up.
I'm sure others will have something to say on this.
Bring on Blackstone please (which no doubt will still support CFLOCK).
MM have made CF fast so we as developers need to make it secure when
handling persistent data.
My 2 cents ;)
Peter Tilbrook
ColdFusion Applications Developer
ColdGen Internet Solutions
Manager, ACT and Region ColdFusion Users Group - http://www.actcfug.com
<http://www.actcfug.com/>
4/73 Tharwa Road
Queanbeyan, NSW, 2620
AUSTRALIA
Tech Support: "What does the screen say now?"
Customer: "It says, 'Hit ENTER when ready'."
Tech Support: "Well?"
Customer: "How do I know when it's ready?"
________________________________
From: Conan Saunders [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 10 March 2004 8:09 PM
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]
