That's my understanding too - the code provided at the start of this thread
is an implementation of the singleton design pattern, so the double lock is
required:
 
http://coldfusion.sys-con.com/read/42048.htm

  _____  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando
Sent: 19 March 2007 21:48
To: [email protected]
Subject: Re: [CFCDEV] Newbie - Utility cfc's in application scope


I think it's important to double lock the instantiation of application
scoped CFCs.

Here, without a lock, i suppose you could get some errors out of this with
requests passing through before the CFC was fully initialized if a function
in this Utility lib was needed immediately, or without a double lock, you
could wind up creating several instances of this CFC in memory before one
finally kept the pointer and getting a few errors as above

When a server is recycled, you can have waiting requests that come thru in a
surge at application startup, even on a low traffic site.

? or am i missing something ?


Alpino, Justin wrote: 

 

Hi J,



I don't think it's necessary to lock when copying your object from

application to request, or even on instantiation unless it will prevent

against a race condition. Shared scopes in MX are synchronized and will

have 'locks' implicitly performed on them when their state is changed

(added to, updated or items removed). If you are unsure, lock to be

safe.



Thanks,



Justin





"The sender believes that this E-mail and any attachments were free of any
harmful and malicious code or defects when sent. The sender is not liable
for any loss or damage arising in any way from this message or its
attachments. 





Confidentiality Note:  This e-mail is intended only for the person or entity
to which it is addressed and may contain information that is privileged,
confidential or otherwise protected from disclosure.  Dissemination,
distribution or copying of this e-mail or the information herein by anyone
other than the intended recipient, is prohibited.  If you have received this
e-mail in error, please inform the sender, and destroy the original message
and all copies."







You are subscribed to cfcdev. To unsubscribe, please follow the instructions
at http://www.cfczone.org/listserv.cfm



CFCDev is supported by:

Katapult Media, Inc.

We are cool code geeks looking for fun projects to rock!

www.katapultmedia.com



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





  



-- 


 <http://aria-media.com/> 


Aria Media Sagl
CP 234
6934 Bioggio
Switzerland
www.aria-media.com <http://aria-media.com/> 






You are subscribed to cfcdev. To unsubscribe, please follow the instructions
at http://www.cfczone.org/listserv.cfm

CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com

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


You are subscribed to cfcdev. To unsubscribe, please follow the instructions at 
http://www.cfczone.org/listserv.cfm

CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com

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

Attachment: emailLogo.gif
Description: GIF image

Reply via email to