Locking in CFMX is never needed to protect variable integrity, so you don't
have to lock all over the place as you did in CF5 and before.
Where you do have to lock is when a given operation isn't a single step, and
it's important that the steps aren't interrupted, done out of order, or done
more than once. Assigning a variable is a single step. Computing a new
value for a variable, based on the old value is more than one step.
For example:
<cfset application.approot = expandPath(".") />
That doesn't need locking, because it's one step, and it doesn't matter if
it's done more than once.
<cfset application.myCFC = createObject("component", "path.to.cfc") />
<cfset application.myCFC.init(application.approot) />
This one DOES need locking, because it's imperitive that the cfc doesn't get
called between the two statements. Note that even though we're using the
application.approot variable, we still wouldn't have to lock setting or
using it, we just need to lock the multi-step CFC initialization.
That's really simplified, and doesn't touch on all the topics related to
locking, but hopefully it's a little easier to understand.
Cheers,
barneyb
> -----Original Message-----
> From: Hoe [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 10, 2004 12:17 PM
> To: CF-Talk
> Subject: RE: Using <cflock and when under different circumstances
>
> Sorry but your answer kinda went over my head.
>
> On Thu, 10 Jun 2004 10:40:23 -0700, Barney Boisvert wrote:
>
> >In CFMX you never need to lock shared scopes just because
> they're shared
> >scopes (this is a change from previous versions). Now you
> only need to
> >worry about race conditions.
> >
> >Think of your shared scopes as a primitive database, with
> each scope as a
> >table, and each individual variable as a record. The
> session scope is kind
> >of special, because it is bound to a user, so you'd actually
> have a "table"
> >for each user's session. You still need to lock though, in
> case they have
> >two browsers open, you're using a frameset, or whatever.
> >
> >CFLOCK is required any place you would need to use a
> transaction to ensure
> >atomicity if you were actually talking to a database. If
> you're modifying a
> >single variable, you don't need a transaction (a single
> statement is always
> >atomic). If you're setting multiple unrelated variables, same thing,
> >because each can be treated as an individual action. If
> you're doing any
> >kind of relative thing (such as reading, perforing an
> operation, and writing
> >the result), you'd need a transaction, and therefore need CFLOCK.
> >
> >Keep in mind that CFLOCK can only lock entire scopes (I'm
> ignoring the
> >'name' attribute), which is equivalent to locking an ENTIRE
> TABLE in our
> >database analogy. That means that using too much locking
> has a definite
> >negative effect, as it will cause access to the shared
> scopes to become
> >single-threaded, greatly reducing concurrency. So just like
> with income
> >tax, lock as little as possible, but never less than you have to.
> >
> >Cheers,
> >barneyb
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
