> macromedia has made the statment that you should avoid this
> by spending time to lock the variable.
You are certainly safer if you follow that approach, in the sense that you
no longer have to think about concurrency as much, but I'd generally
recommend that learning about concurrency is a better approach than using
locks unnecessarily. Locks are, by their very nature, bottlenecks in a
multi-user environment, and shouldn't be used if they're not needed.
> Assuming the worst case (because of lack of evidence to the
> contrary), the variable gets corrupted by this action. I
> would think that the server might be negatively affected by
> such an occurence and indeed might crash. Cf5 would crash
> when its variables became corrupted. So, perhaps it might be
> somewhat important?
The worst case with CFMX, according to Macromedia, is that you may have the
wrong value in your variable as a result of a race condition. This is
essentially a logical error, rather than a "real" error that causes CF to
stop processing your code. Obviously, if you're concerned about having the
wrong value in your variable, you'd want to synchronize access to that
variable in a controlled way, and that's what the CFLOCK tag is for.
The same issues arise in any multi-user environment, such as a relational
database. That's why most relational databases lock data by default during a
transaction, and why understanding transactional processing, locking, and
isolation levels is so important to database programmers. But there are
cases where locking might not be that important even within a relational
database, such as reporting. Competent database programmers - and, of
course, that includes competent CF programmers - should understand
concurrency issues well enough to decide on a case-by-case basis whether to
lock or not.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
