This email is to be read subject to the disclaimer below.
Mark,
To quote the docs "An exclusive lock single-threads access to the CFML
constructs in its body". So yes, it will prevent the same code (eg query)
running at the same time.
<todays useless trivia>It's worth mentioning that race conditions arise
from the fact that in a multitasking operating system the hardware clock
generates interrupts that periodically wake up the operating system's
scheduler. The scheduler then can decide to pause the currently executing
process (regardless of what it's up to at that precise moment) and run
another one instead. And Murphy's law implies that if there are two
cfserver threads processing the same request, the scheduler will pause the
first one right when it's processed a <cfif> and before it got to the
<cfquery> inside it. Then it would run the other thread to completition,
allowing it to insert the record. Then it would resume the first thread,
allowing that to complete the <cfquery> as well. :-)
To get around this problem, a special assembly instruction called TSL (test
and set lock) is used. This is then abstracted by the operating system into
a thing called 'semaphore'. And I assume that cflock uses semaphores
internally to achieve mutual exclusion</todays useless trivia>
HTH
Vik
---------------------
Viktor Radnai
Web Developer, National E-Commerce, Ernst & Young
Direct: +61 2 9248 4361
"Mark Stanton"
<[EMAIL PROTECTED]> To: "CFAussie Mailing
List" <[EMAIL PROTECTED]>
Sent by: cc:
[EMAIL PROTECTED] Subject: [cfaussie] RE: stopping the
double click effect
mon.com.au
27/03/2003 03:31 PM
Please respond to "CFAussie
Mailing List"
There are a number of similar situations in the site but the one that got
me
on this topic today was a self registration form for users from a specific
company. The user goes to the form & enters their first name, last name &
email address.
I've got various user types & levels, but everyone who comes in from this
form will have the same properties. There are also status' that relate to
users.
My business rule is that I can only have one email address (username) that
is of this type and level & has a status of active. So before I begin at
activating the registration I query the database to see if there are any
records that meet this criteria if the record count is 0 I continue with
the
registration - if not I output an error message "You have already
registered
for this service" and exit.
So....
Back buttons should not be a problem, neither should visiting the form a
week later & trying to register. The only way I can see duplicate entries
popping up is if I have 2 (or more) simultaneous registration requests.
To put it in context we've has over 2000 people use this form in the last 2
months and of these there have been 8 duplicates. Its not a huge problem
but
its time consuming cleaning up the mess. All of these users are from one
organisation and I know that there are major IT infrastructure problems,
for
example they often have a 2 hour que on the email server ("Have you got
that
email yet?" "Um no." "OK I'll call back tomorrow, it should have arrived by
then").
----------------
3.) Surround the above code with a <cflock name="#Form.UUID#" type
="exclusive"> to guard against race conditions
----------------
This is what I want to know! Can does cflock prevent all enclosed code
being
run simultaneously or does it just prevent reading & writing of session,
application & server variables?
If so then this should be all I need to do, because I am already using my
email address form input as a unique identifier.
Thanks for the help everyone :)
Cheers
Mark
______________
Mark Stanton
Web Production
Gruden Pty Ltd
Tel: 9956 6388
Mob: 0410 458 201
Fax: 9956 8433
www.gruden.com
---
You are currently subscribed to cfaussie as:
[EMAIL PROTECTED]
To unsubscribe send a blank email to
[EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
--------------------
NOTICE - This communication contains information which is confidential and
the copyright of Ernst & Young or a third party.
If you are not the intended recipient of this communication please delete
and destroy all copies and telephone Ernst & Young on 1800 655 717
immediately. If you are the intended recipient of this communication you
should not copy, disclose or distribute this communication without the
authority of Ernst & Young.
Any views expressed in this Communication are those of the individual
sender, except where the sender specifically states them to be the views of
Ernst & Young.
Except as required at law, Ernst & Young does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained nor
that the communication is free of errors, virus, interception or
interference.
Liability limited by the Accountants Scheme, approved under the
Professional Standards Act 1994 (NSW)
--------------------
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
