> 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]
