> -----Original Message-----
> From: James Holmes [mailto:[EMAIL PROTECTED]
> Sent: Saturday, September 02, 2006 5:43 AM
> To: CF-Talk
> Subject: Re: Locking (no, not pop-locking)
>
> Locking in CF7 is now only necessary if you could encounter a race
> condition, so that you always get the correct value in/from the
> variable. The memory corruption seen without locking in CF5 and below
> is a thing of the past.
Scoped locks are rarely, if ever, needed any longer, but named locks are
still as useful as ever.
Using locks to ensure proper code serialization is always good practice.
For example say you have some code like this (pseudo-code, in case you can't
tell) which is popular in application initialization:
<cfif we don't have a cache>
<Do a giant, ugly, loooooong Database Query>
<Cache the query results in the application scope>
</cfif>
This works well IF you're not under any load. If you have any load however
you'll launch that query several times since several requests will find that
the cache doesn't exist.
(Yes... granted it may not as popular as it once was now that we have
application.cfm but you get the point.)
Any process that needs to be run only once (but needs to be run before
continuing) can benefit from locking. Verity operations come to mind for
example - a reindex may take a short while on a small site but you still
don't want several reindex requests to be issued at the same time.
There are also cases where you might want to limit the access to some code
to fewer people than you've allotted threads. You can build your own system
to prevent this but instead you can build only part of it (a named lock
pool) and let the built-in locking capability handle the code.
Say you had a search interface that was (as is sometimes the case) a little
slow. Although you might have 20 threads open for the application you might
only want four people at once launch a search.
You could crap this call to the search in a named lock - but the name used
could be a variable.
You might create a pool of four named locks ("MyLock1", "MyLock2", etc).
When somebody requested the feature all you would need to is either assign
them a random lock name or loop through the lock names.
In short all you have to do is make sure that the lock names are distributed
(at least somewhat) evenly. The user would then call the code with the lock
name.
The locking engine would prevent more than four people from entering the
code with no more work on your part.
There are a lot more examples of this kind of thing (something doable
perfectly well without named locks but easier with them).
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting,
up-to-date ColdFusion information by your peers, delivered to your door four
times a year.
http://www.fusionauthority.com/quarterly
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251859
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
