I think you made some valid points. To create a cf lock like
<cflock name='session' ...> is totally and obviously senseless.
Don
>> [Tom Kitta]
>> Well, as always in these situations I did a quick check as
>> how things are in
>> the real life. Here is my code:
>> <cfset mm = GetTickCount()>
>
>> <cfloop index="m" from="1" to="10000" step="1">
>> <cflock timeout="30" throwontimeout="Yes"
>> type="EXCLUSIVE" scope="SESSION">
>> <cfset session.blob = 123>
>> </cflock>
>> </cfloop>
>
>> <cfoutput>Scoped: #GetTickCount() - mm#</cfoutput><br>
>
>> <cfset ww = GetTickCount()>
>
>> <cfloop index="m" from="1" to="10000" step="1">
>> <cflock timeout="30" throwontimeout="Yes"
>> name="hfjdshfkshfks"
>> type="EXCLUSIVE">
>> <cfset session.bleeh = 123>
>> </cflock>
>> </cfloop>
>
>> <cfoutput>Named: #GetTickCount() - ww#</cfoutput><br>
>
>
>> I didn't see any performance differences. Maybe it is
>> apparent with more variables used?
>
>The problem with this code as a test case isn't so much that you're
>not using many variables, but that generally speaking, you're not
>going to see the cflock actually doing anything in this case. It's a
>single template, so everything within this single template is
>single-threaded (within a given request) already. Unless you've got
>several different browsers hitting that same page simultaneously, it
>will perform almost as though no locking had been included at all (any
>difference shouldn't be humanly noticeable). Differences in
>performance between the named lock and the session lock will occur
>based on the number of simultanous requests to (exclusively) lock the
>given item. So because any of the scopes should preferably share more
>variables (and be in heavier use) than a named lock (such as
>getcurrenttemplatepath()), the scope locks when used will lock the
>scope more frequently than a named lock, increasing the odds of two
>requests to lock the scope occuring simultaneously. So the queue to
>receive a lock on a scoped lock section fills up faster than the queue
>to receive a lock on a named section (provided you've used a
>reasonably specific name). The larger the queue, the longer it takes
>to single-thread through all the requests for that lock.
>
>Does this all make sense of have I made it as clear as mud? :)
>
>> Incidentally I noticed a lot of people
>> using createUUID()
>> for the named locks. Wow, performance dies right there.
>
>I don't know about peformance, but with <cflock name="#createuuid()#">
>you may as well not lock at all, since each instance of the tag will
>have a unique name, you'll never get any locking and your race
>conditions will persist.
>
>> You can run it yourself from:
>> http://dev.energyshop.com/tk/mytest.cfm
>> [Tom Kitta]
>> I think it might also be a personal preferance.
>
>Yes and no. As long as the application runs fast enough to not be
>problematically slow then you're fine. If you find that an application
>under load is running slow or certain sections are running slow, in
>some cases you might find that switching from scope locks to name
>locks or improving the names on certain locks can improve performance.
>Though it's tough to define any hard-and-fast rules for handling
>race-conditions.
>
>
>s. isaac dealey 214.823.9345
>
>new epoch : isn't it time for a change?
>
>add features without fixtures with
>the onTap open source framework
>http://www.sys-con.com/story/?storyid=44477&DE=1
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
