I think maybe some mis-communication here.
>i don't think there's much of any reason to create an object and
place it in application scope unless you make it a singleton that persists
until the application scope times out
I agree.
>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 was trying to make the point that because you are making a variable in app
scope, there will only ever be one, even without the lock.
request 1
causes appstart to run
creates application.myobj
request 2
happens before request 1 is finished initialising the app, causes
appstart
to run
creates application.myobj, overwriting the one created by request 1
request 3
app is initialised, appstart not run.
application.myobj is still a singleton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Nando
Sent: 13 May 2005 10:53
To: [email protected]
Subject: RE: SPAM-LOW: RE: [CFCDev] Singleton / Factory request
Kerry, i don't think there's much of any reason to create an object and
place it in application scope unless you make it a singleton that persists
until the application scope times out. At least i can't think of one.
The MM docs say that if you create an object in Application.cfc's
onApplicationStart() method (CFMX7) and place it in application scope,
you'll get a singleton. The underlying machinery there will ensure that. Ok,
i believe them ...
If you need some functionality elsewhere in your application on occasion,
and also on "onAppStart" ... i'd put that in it's own method and call that
method from within onApplicationStart() to seperate ... intelligently
modularize the two things. How does that sound?
:) n
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Kerry
Sent: Friday, May 13, 2005 11:07 AM
To: [email protected]
Subject: RE: SPAM-LOW: RE: [CFCDev] Singleton / Factory request
but, if you are creating the object in app scope, and x number of requests
cause the appstart code to run, then each subsequent request will overwrite
the last one, so there will still only be one instance of the object?
in saying that, I would do the lock because its nice and tidy.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Nando
Sent: 12 May 2005 21:11
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]
----------------------------------------------------------
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]
