On Monday, Oct 7, 2002, at 01:38 US/Pacific, Kola Oyedeji wrote:
> I'm joining this thread late. Can I just confirm what you guys are
> saying: In CFMX named locks should be used in place of scoped locks and
> locks are only needed When a possible race condition could occur?
The last part is relatively easy to answer: yes, you only need locks
when a race condition could occur.
The first part is slightly harder to answer: in general, named locks
allow finer grained control over locking and therefore will cause fewer
lock contentions between requests. Consider a couple of variables in
server scope: in CF5 (and earlier) you had to use scope="server" to
protect access to such variables so any code accessing one of those
variables would block any code accessing the other variable. In CFMX,
it is safe to use a named lock instead, with a different lock name for
each variable:
<!--- page1.cfm : CF5 scoped lock --->
<cflock scope="server" type="exclusive">
<cfset server.a = 42>
</cflock>
<!--- page2.cfm : CF5 scoped lock --->
<cflock scope="server" type="exclusive">
<cfset server.b = 77>
</cflock>
While page1.cfm is executing, page2.cfm would block. In CFMX you can do
this:
<!--- page1.cfm : CFMX named lock --->
<cflock scope="server_a" type="exclusive">
<cfset server.a = 42>
</cflock>
<!--- page2.cfm : CFMX named lock --->
<cflock scope="server_b" type="exclusive">
<cfset server.b = 77>
</cflock>
Now the pages won't block each other (obviously multiple requests to
page1.cfm will block each other but page2.cfm wouldn't be affected).
That's easy enough for application and server scope because the name is
easy to figure out. For session scope, you need a name that is unique
to your session which may be harder to invent (you could perhaps use a
user ID if it exists or a per-session UUID). OTOH, race conditions
within session scope are probably going to be rarer because they can
only occur if you have multiple windows or frames open with the same
session data (frames are evil, in my opinion, so I'm not very
sympathetic to people who get into a session integrity mess when they
use frames! :)
If it's too hard to come up with a unique name for your lock, using
scope= may be the easiest solution for you. Since the shared scope
corruption problem is no longer an issue in CFMX, there are many cases
where you safely omit the lock altogether (for example, if the
assignment is 'atomic' and all request would store the same value - or
it doesn't matter which request actually stores the value, e.g., the
application just needs *a* value in the shared scope variable).
Hope that helps clarify?
An Architect's View -- http://www.corfield.org/blog/
Macromedia DevCon 2002, October 27-30, Orlando, Florida
Architecting a New Internet Experience
Register today at http://www.macromedia.com/go/devcon2002
An Architect's View -- http://www.corfield.org/blog/
Macromedia DevCon 2002, October 27-30, Orlando, Florida
Architecting a New Internet Experience
Register today at http://www.macromedia.com/go/devcon2002
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community. http://www.fusionauthority.com/ads.cfm
