What about a <cfloop thats calling in a SESSION.varaible like below. Does it also get wrapped with <cflock>?
I'm really confused.
<cflock timeout="10" type="EXCLUSIVE" scope="SESSION">
<cfloop index=List list="#SESSION.name#">
</cfloop>
</cflock>
On Thu, 10 Jun 2004 12:43:47 -0700, Barney Boisvert wrote:
>I'll simplify (hopefully).
>
>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]
