Well I'll take a race any day instead of a deadlock ;-)
Think about it in a different way - the worst case would be that two threads
detect the structure is not defined and then:
The first acquires a write lock (blocking any others from reading and
detecting it's not defined)
Writes the data
Releases the lock.
The second acquires a write lock
Writes the SAME data
Releases the lock.
It's not really a critical race since both outcomes are the same regardless
of who "wins" all you get is a very remote chance of a performance hit - two
hits on the DB - when you reboot your server.
Bottom line - don't worry be :-).
----------
From: Dustin Breese [SMTP:[EMAIL PROTECTED]]
Sent: Monday, 28 August 2000 18:57
To: [EMAIL PROTECTED]
Subject: RE: No more need for cflock!!
Whopps...good catch....
However, you still get a race condition where multiple threads can
initialize the code. If you exit the read lock with a pre-chosen
path to
initialize, then multiple threads can decide to initialize and will
simply
wait their turn in the queue before initializing.
Am I missing something else? (Highly likely!)
An exclusive lock isn't optimal, so what is the solution? Maybe the
second
body needs to do another check wrapped inside the EXCLUSIVE lock to
make
sure it still is not defined? That case would seem to catch any of
the
threads that slipped past, right?
-Dustin
-----Original Message-----
From: BOROVOY Noam [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 28, 2000 10:30 AM
To: [EMAIL PROTECTED]
Subject: RE: No more need for cflock!!
Careful,
Can't do that - see below:
----------
From: Dustin Breese [SMTP:[EMAIL PROTECTED]]
Sent: Monday, 28 August 2000 18:09
To: [EMAIL PROTECTED]; Fusebox
Subject: RE: No more need for cflock!!
Steve,
Only suggestion I would make here is to put the
initialization code
inside
the CFLOCK -- it keeps multiple threads from running the
same init
logic.
Probably a low possibility, but it could definitely happen
in a
high-transaction environment. Just in case the init logic
is a
big-hitter!
For example:
<cflock name="#application.applicationname#" timeout="60"
type="readonly">
<cfif not isdefined("application.requestapp")>
<!--- DO THE INIT LOGIC WITHIN THE LOCK, NOT
WITHOUT
--->
Here you need to have a write lock NOT a read lock - but you
can't
acquire one because you've already read locked
Instead - First check if the variable is defined - does not
require
a lock -if it's not then Write lock and Init
</cfif>
<cfset request.app=application.requestapp>
</cflock>
Just my 2-cents!
-Dustin
-----Original Message-----
From: Steve Nelson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 26, 2000 8:34 AM
To: Fusebox
Subject: No more need for cflock!!
I've just hit upon a technique that would mean we only ever
need to
use
cflock two times in a fusebox home application. This is for
application
variables, session and server variables would need to do the
same
too i
imagine (personally i never use them)
First I want to propose a new filename, qry_globals.cfm the
point of
the
file is to store application wide queries, it would sit in
the root
directory of your home application. It would run queries
from the
database upon booting up the server then store the variables
into
memory. This massively reduces stress on the database,
generally
it's
an excellent technique. The problem has been with cflock.
people
forget to use it and CF WILL blow up on you if you forget to
use
CFLOCK. So I figured out a way to bypass all the cflock
nonsense
and
only require two cflocks in your entire application, which
do very
small
tasks.
Check this code out. It's wicked cool (Hal let me know how
I did
on my
fusedocs, i'm just starting to get into them, and love 'em!
:)
<cfsetting enablecfoutputonly="yes">
<!--- qry_globals.cfm --->
<!---
|| I start by doing a check to see if the variable
application.requestapp exists if this
|| variable exists then I set
request.app=application.requestapp and
I
do not rerun any
|| application wide queries. If this variable does not
exist I
rerun
all the queries
|| and set application.requestapp=request.app
||
|| Then anytime I want one of these values I call it as:
request.app.queryname instead
|| of application.queryname. By doing this I no longer need
to use
cflock in anywhere
|| other than this file.
|| [EMAIL PROTECTED]
||
-->
<-- request.app - this is a copy of an application variable
called
application.requestapp
++> application.requestapp - this is where all application
wide
queries
sit
+++
--->
<cfset request.maindsn="valuemusiclocal">
<cfapplication name="blbl"
applicationtimeout="#createtimespan(0,1,0,0)#">
<cflock name="#application.applicationname#" timeout="60"
type="readonly">
<cfif isdefined("application.requestapp")>
<cfset request.app=application.requestapp>
<cfset runrequest="no">
<cfelse>
<cfset runrequest="yes">
</cfif>
</cflock>
<cfif runrequest>
<cfset request.app=structnew()>
<cfquery name="request.app.getstates"
datasource="#request.maindsn#">
select * from states
where active=1
order by state_name
</cfquery>
<cfset request.app.state_rows=structnew()>
<cfloop query="request.app.getstates">
<cfset
request.app.state_rows[state_id]=currentrow>
</cfloop>
<cflock name="#application.applicationname#"
timeout="60"
type="exclusive">
<cfset application.requestapp=request.app>
</cflock>
</cfif>
<cfsetting enablecfoutputonly="no">
<!--- dsp_address.cfm --->
<!---
|| I'm demonstrating the use of a request.app variable, note
that
|| I do not need cflock, and I do not need to rerun the
getstates
query
|| [EMAIL PROTECTED]
||
-->
<--
++> request.app.getstates - this is a query with all the
states in
it
+++
--->
<select name="state_id">
<cfoutput query="request.app.getstates">
<option value="#state_id#">#state_name#
</cfoutput>
</select>
Now that's a beautiful thing! eh?
Steve
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with
'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with
'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with
'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with
'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
