In theory, you don't need to lock if the assignment is to the application
scope and is in the onApplicationStart() method of your application because
it is only ever called once.  That is, unless you use onApplicationStart
later to simulate a restart, but that's arguably hackery....

Either way - even if you don't need it in onApplicationStart, you _do_ need
it anywhere else you _write_ to an application or session variable.  So if
you want to be consistent, just lock it in app.cfc as well - it can't hurt,
and it is consistent with the other locking rules.

My .02
Roland

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Nando
Sent: Thursday, May 12, 2005 4:11 PM
To: [email protected]
Subject: RE: SPAM-LOW: RE: [CFCDev] Singleton / Factory request

I'll contradict Peter here and say that yes you do need to lock that code
block as shown for the reason stated if you want to guarentee that one and
only one instance of that object can exist.

I assumed you were on MX7, because you referred to Application.cfc, but i
guess you meant Application.cfm

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Peter J. Farrell
Sent: Thursday, May 12, 2005 9:42 PM
To: [email protected]
Subject: Re: SPAM-LOW: RE: [CFCDev] Singleton / Factory request


Peter H wrote:

> On the subject of locking, I'm using cf6.1 - do I still need to lock?

No, unless you are trying a to prevent a race condition.  The archives
have a lot about race conditions as well as a few articles on Macr.

Best,
.Peter

--
Peter J. Farrell :: Maestro Publishing

blog    :: http://blog.maestropublishing.com
email   :: [EMAIL PROTECTED]

Create boilerplate beans!
Check out the Mach-II Bean Creator - free download.
http://blog.maestropublishing.com/mach-ii_beaner.htm

You need only two tools: WD-40 and Duct Tape
If it doesn't move and it should, use WD-40.
If it moves and shouldn't, use the duct tape.
--



----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]






----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]







----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to 
[email protected] with the words 'unsubscribe cfcdev' as the subject of the 
email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting 
(www.cfxhosting.com).

CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]


Reply via email to