The Singleton Provider code is not thread safe (since it does not lock
modifications of variables scope which is essentially application
scope). This is why literal implementations of the Singleton pattern
is so hard in C++ / Java etc - synchronization, threading (and
preventing multiple instance creation).
The Singleton Provider doesn't prevent multiple instances because you
can simply create multiple provider objects. It really provides no
value and simply adds complexity. IMO.
Folks either need to go with something battle-tested like ColdSpring
to manage singletons or stick with the simple onApplicationStart()
approach.
-- Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/ An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
I'm taking the approach that we can't enforce singletons in CFML in any
reasonable way, so it is more by convention that a provider should be
created once on application startup.
I proabably didn't get the idea across too well, but the Singleton Provider
is a intended to be a pattern that represents an object factory for
singletons. I think there is value to include it because of the common usage
of factories to manage singletons. Perhaps the pattern itself should be
called Singleton Factory?
Considering what you've mentioned I may include a section that refers to
ColdSpring and perhaps Lightwire.
> The Singleton Provider code is not thread safe (since it does not lock
> modifications of variables scope which is essentially application
> scope). This is why literal implementations of the Singleton pattern
> is so hard in C++ / Java etc - synchronization, threading (and
> preventing multiple instance creation).
> The Singleton Provider doesn't prevent multiple instances because you
> can simply create multiple provider objects. It really provides no
> value and simply adds complexity. IMO.
> Folks either need to go with something battle-tested like ColdSpring
> to manage singletons or stick with the simple onApplicationStart()
> approach.
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/ > An Architect's View -- http://corfield.org/
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
<kevanstann...@gmail.com> wrote:
> I proabably didn't get the idea across too well, but the Singleton Provider
> is a intended to be a pattern that represents an object factory for
> singletons. I think there is value to include it because of the common usage
> of factories to manage singletons. Perhaps the pattern itself should be
> called Singleton Factory?
I think the problem with what's there right now is people will see the
simple singleton wrapper and mindlessly follow it with understanding
you mean a factory (that can create a number of different singletons).
-- Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/ An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
> On Fri, Dec 11, 2009 at 12:41 AM, Kevan Stannard
> <kevanstann...@gmail.com> wrote:
> > I proabably didn't get the idea across too well, but the Singleton
> Provider
> > is a intended to be a pattern that represents an object factory for
> > singletons. I think there is value to include it because of the common
> usage
> > of factories to manage singletons. Perhaps the pattern itself should be
> > called Singleton Factory?
> I think the problem with what's there right now is people will see the
> simple singleton wrapper and mindlessly follow it with understanding
> you mean a factory (that can create a number of different singletons).
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/ > An Architect's View -- http://corfield.org/
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
Understandably Coldspring would be ideal way to create "complex" singletons,
but out of curiosity if a CF developer ever decided to build a singleton
provider class on their own I would think something like the below would
suffice. It's a quick example, but I figure that the application scope would
be encapsulated within the component to help ensure that there is only one
instance of the object application wide. I am curious on everyone's thoughts
on this outside of using Coldspring.
*<cfcomponent name="singletonAProvider">
<cffunction* name="getInstance" output="false">
*<cfif* not structKeyExists(application,"singletonA")>
> Yep, I see what you mean. I'll rework it a bit, thanks.
> 2009/12/11 Sean Corfield <seancorfi...@gmail.com>
>> On Fri, Dec 11, 2009 at 12:41 AM, Kevan Stannard
>> <kevanstann...@gmail.com> wrote:
>> > I proabably didn't get the idea across too well, but the Singleton
>> Provider
>> > is a intended to be a pattern that represents an object factory for
>> > singletons. I think there is value to include it because of the common
>> usage
>> > of factories to manage singletons. Perhaps the pattern itself should be
>> > called Singleton Factory?
>> I think the problem with what's there right now is people will see the
>> simple singleton wrapper and mindlessly follow it with understanding
>> you mean a factory (that can create a number of different singletons).
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> Railo Technologies US -- http://getrailo.com/ >> An Architect's View -- http://corfield.org/
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Object-Oriented Programming in ColdFusion" group.
>> To post to this group, send email to coldfusionoo@googlegroups.com.
>> To unsubscribe from this group, send email to
>> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/coldfusionoo?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
I forgot to mention. I thought of the application scope because it's the
closest thing to the global scope in java even though it can't be fully
protected.
On Fri, Dec 11, 2009 at 7:47 AM, Patrick Santora <patwe...@gmail.com> wrote:
> Understandably Coldspring would be ideal way to create "complex"
> singletons, but out of curiosity if a CF developer ever decided to build a
> singleton provider class on their own I would think something like the below
> would suffice. It's a quick example, but I figure that the application scope
> would be encapsulated within the component to help ensure that there is only
> one instance of the object application wide. I am curious on everyone's
> thoughts on this outside of using Coldspring.
> *<cfcomponent name="singletonAProvider">
> <cffunction* name="getInstance" output="false">
> *<cfif* not structKeyExists(application,"singletonA")>
> On Fri, Dec 11, 2009 at 12:50 AM, Kevan Stannard <kevanstann...@gmail.com>wrote:
>> Yep, I see what you mean. I'll rework it a bit, thanks.
>> 2009/12/11 Sean Corfield <seancorfi...@gmail.com>
>>> On Fri, Dec 11, 2009 at 12:41 AM, Kevan Stannard
>>> <kevanstann...@gmail.com> wrote:
>>> > I proabably didn't get the idea across too well, but the Singleton
>>> Provider
>>> > is a intended to be a pattern that represents an object factory for
>>> > singletons. I think there is value to include it because of the common
>>> usage
>>> > of factories to manage singletons. Perhaps the pattern itself should be
>>> > called Singleton Factory?
>>> I think the problem with what's there right now is people will see the
>>> simple singleton wrapper and mindlessly follow it with understanding
>>> you mean a factory (that can create a number of different singletons).
>>> --
>>> Sean A Corfield -- (904) 302-SEAN
>>> Railo Technologies US -- http://getrailo.com/ >>> An Architect's View -- http://corfield.org/
>>> "If you're not annoying somebody, you're not really alive."
>>> -- Margaret Atwood
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Object-Oriented Programming in ColdFusion" group.
>>> To post to this group, send email to coldfusionoo@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
>>> .
>>> For more options, visit this group at
>>> http://groups.google.com/group/coldfusionoo?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Object-Oriented Programming in ColdFusion" group.
>> To post to this group, send email to coldfusionoo@googlegroups.com.
>> To unsubscribe from this group, send email to
>> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/coldfusionoo?hl=en.
On Fri, Dec 11, 2009 at 7:47 AM, Patrick Santora <patwe...@gmail.com> wrote:
> <cfif not structKeyExists(application,"singletonA")>
> <cfset application.singleton =
> createObject("component","SingletonA").init()>
> </cfif>
You still want if / lock / if here to avoid a race condition that can
construct SingletonA twice!
-- Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/ An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
> On Fri, Dec 11, 2009 at 7:47 AM, Patrick Santora <patwe...@gmail.com>
> wrote:
> > <cfif not structKeyExists(application,"singletonA")>
> > <cfset application.singleton =
> > createObject("component","SingletonA").init()>
> > </cfif>
> You still want if / lock / if here to avoid a race condition that can
> construct SingletonA twice!
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/ > An Architect's View -- http://corfield.org/
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
* Renamed Singleton Provider to Singleton Factory
* The example creates the singletons when the factory is created - no lazy
instantiation, and the example shows the factory being created in
onApplicationStart() so I have not included locking.
* I have included an additional example of singleton management using
ColdSpring. Considering that was the intent of the original "singleton
provider" this hopefully introduces a real world example of more advanced
singleton management.
What does everyone think? Is this representative of how singletons should be
managed in CFML?
Pat and I have discussed this approach and I can see that there is a place
for code that encapsulates access to the application scope, but I am not
convinced it should be promoted as a technique for managing singletons.
> Ah of course. Sounds like a yes as long as the lock is in place.
> On Fri, Dec 11, 2009 at 9:00 AM, Sean Corfield <seancorfi...@gmail.com>wrote:
>> On Fri, Dec 11, 2009 at 7:47 AM, Patrick Santora <patwe...@gmail.com>
>> wrote:
>> > <cfif not structKeyExists(application,"singletonA")>
>> > <cfset application.singleton =
>> > createObject("component","SingletonA").init()>
>> > </cfif>
>> You still want if / lock / if here to avoid a race condition that can
>> construct SingletonA twice!
>> --
>> Sean A Corfield -- (904) 302-SEAN
>> Railo Technologies US -- http://getrailo.com/ >> An Architect's View -- http://corfield.org/
>> "If you're not annoying somebody, you're not really alive."
>> -- Margaret Atwood
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Object-Oriented Programming in ColdFusion" group.
>> To post to this group, send email to coldfusionoo@googlegroups.com.
>> To unsubscribe from this group, send email to
>> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/coldfusionoo?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
Understandable but a viable approach to the pattern nevertheless.
I an curious what other people think as this example (unless wrong) is
a GoF expressed example and an understandably good one when working
outside of the onapplicationstart method approach.
Just another duck on the table :)
Sent from my iPhone
On Dec 11, 2009, at 6:26 PM, Kevan Stannard <kevanstann...@gmail.com>
wrote:
> Pat and I have discussed this approach and I can see that there is a
> place for code that encapsulates access to the application scope,
> but I am not convinced it should be promoted as a technique for
> managing singletons.
> 2009/12/12 Patrick Santora <patwe...@gmail.com>
> Ah of course. Sounds like a yes as long as the lock is in place.
> On Fri, Dec 11, 2009 at 9:00 AM, Sean Corfield
> <seancorfi...@gmail.com> wrote:
> On Fri, Dec 11, 2009 at 7:47 AM, Patrick Santora
> <patwe...@gmail.com> wrote:
> > <cfif not structKeyExists(application,"singletonA")>
> > <cfset application.singleton =
> > createObject("component","SingletonA").init()>
> > </cfif>
> You still want if / lock / if here to avoid a race condition that can
> construct SingletonA twice!
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/ > An Architect's View -- http://corfield.org/
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> --
> You received this message because you are subscribed to the Google
> Groups "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to coldfusionoo+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/coldfusionoo?hl=en > .
> --
> You received this message because you are subscribed to the Google
> Groups "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to coldfusionoo+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/coldfusionoo?hl=en > .
> --
> You received this message because you are subscribed to the Google
> Groups "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to coldfusionoo+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/coldfusionoo?hl=en > .
Of course the GoF approach has nothing about onapplicationstart in it
for obvious reasons. It just seems like a good approach to manage
singleton creation outside of the onapplicationstart method when not
having something like coldspring available.
Btw this is not meant to shove its way into the existing
documentation. Curiosity just has my fingers talking. :)
I'm quite excited about the website Kevan!!!
-Pat
Sent from my iPhone
On Dec 11, 2009, at 6:26 PM, Kevan Stannard <kevanstann...@gmail.com>
wrote:
> Pat and I have discussed this approach and I can see that there is a
> place for code that encapsulates access to the application scope,
> but I am not convinced it should be promoted as a technique for
> managing singletons.
> 2009/12/12 Patrick Santora <patwe...@gmail.com>
> Ah of course. Sounds like a yes as long as the lock is in place.
> On Fri, Dec 11, 2009 at 9:00 AM, Sean Corfield
> <seancorfi...@gmail.com> wrote:
> On Fri, Dec 11, 2009 at 7:47 AM, Patrick Santora
> <patwe...@gmail.com> wrote:
> > <cfif not structKeyExists(application,"singletonA")>
> > <cfset application.singleton =
> > createObject("component","SingletonA").init()>
> > </cfif>
> You still want if / lock / if here to avoid a race condition that can
> construct SingletonA twice!
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/ > An Architect's View -- http://corfield.org/
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> --
> You received this message because you are subscribed to the Google
> Groups "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to coldfusionoo+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/coldfusionoo?hl=en > .
> --
> You received this message because you are subscribed to the Google
> Groups "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to coldfusionoo+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/coldfusionoo?hl=en > .
> --
> You received this message because you are subscribed to the Google
> Groups "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to coldfusionoo+unsubscribe@googlegroups.com > .
> For more options, visit this group at http://groups.google.com/group/coldfusionoo?hl=en > .
In my Design Patterns preso (originally written for the MAX "Inspire" track
a few years ago) I lampooned how complex all the Java Singleton
implementations are because Java doesn't have:
a) a global scope like application
b) an application start point like onApplicationStart() (the main() method
doesn't count - any class can have that so there's no *single* application
entry point)
c) any easy way to manage when or where a Singleton is actually created
Singleton implementation in ColdFusion is trivial by design.
The whole thing about "preventing more than one instance" is really only
applicable to language implementations where this is likely due to the
points above...
Sean
On Fri, Dec 11, 2009 at 6:18 PM, Kevan Stannard <kevanstann...@gmail.com>wrote:
> * Renamed Singleton Provider to Singleton Factory
> * The example creates the singletons when the factory is created - no lazy
> instantiation, and the example shows the factory being created in
> onApplicationStart() so I have not included locking.
> * I have included an additional example of singleton management using
> ColdSpring. Considering that was the intent of the original "singleton
> provider" this hopefully introduces a real world example of more advanced
> singleton management.
> What does everyone think? Is this representative of how singletons should
> be managed in CFML?
> * Renamed Singleton Provider to Singleton Factory
> * The example creates the singletons when the factory is created - no lazy
> instantiation, and the example shows the factory being created in
> onApplicationStart() so I have not included locking.
> * I have included an additional example of singleton management using
> ColdSpring. Considering that was the intent of the original "singleton
> provider" this hopefully introduces a real world example of more advanced
> singleton management.
> What does everyone think? Is this representative of how singletons should
> be managed in CFML?
> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
On Sat, Dec 12, 2009 at 7:33 AM, Phillip Senn <phillips...@gmail.com> wrote:
> Do you need to lock the application scope, or is that implied in
> onApplicationStart?
onApplicationStart() (and onSessionStart()) are automatically
single-threaded by the CFML engine (so, no, you don't need to lock).
-- Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/ An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
You don't need to lock if you let them run "normally." If you run the
methods manually (many people will add a call to onApplicationStart
inside their onRequestStart if a URL param exist) then you may need a
lock. Of course, you only need a lock if you actually care about a
race condition. 99% of the code I see in application startup just
initializes a set of variables.
On Sat, Dec 12, 2009 at 5:55 PM, Sean Corfield <seancorfi...@gmail.com> wrote:
> On Sat, Dec 12, 2009 at 7:33 AM, Phillip Senn <phillips...@gmail.com> wrote:
>> Do you need to lock the application scope, or is that implied in
>> onApplicationStart?
> onApplicationStart() (and onSessionStart()) are automatically
> single-threaded by the CFML engine (so, no, you don't need to lock).
> --
> Sean A Corfield -- (904) 302-SEAN
> Railo Technologies US -- http://getrailo.com/ > An Architect's View -- http://corfield.org/
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
-- ===========================================================================
Raymond Camden, ColdFusion Jedi Master
Race conditions caused by directly invoking application or session
initialization code often require more thought than simply throwing a cflock
around the call. I decided to write a blog entry to explain:
On Sat, Dec 12, 2009 at 9:25 PM, Raymond Camden <rcam...@gmail.com> wrote:
> You don't need to lock if you let them run "normally." If you run the
> methods manually (many people will add a call to onApplicationStart
> inside their onRequestStart if a URL param exist) then you may need a
> lock. Of course, you only need a lock if you actually care about a
> race condition. 99% of the code I see in application startup just
> initializes a set of variables.
> On Sat, Dec 12, 2009 at 5:55 PM, Sean Corfield <seancorfi...@gmail.com>
> wrote:
> > On Sat, Dec 12, 2009 at 7:33 AM, Phillip Senn <phillips...@gmail.com>
> wrote:
> >> Do you need to lock the application scope, or is that implied in
> >> onApplicationStart?
> > onApplicationStart() (and onSessionStart()) are automatically
> > single-threaded by the CFML engine (so, no, you don't need to lock).
> > --
> > Sean A Corfield -- (904) 302-SEAN
> > Railo Technologies US -- http://getrailo.com/ > > An Architect's View -- http://corfield.org/
> > "If you're not annoying somebody, you're not really alive."
> > -- Margaret Atwood
> --
> ===========================================================================
> Raymond Camden, ColdFusion Jedi Master
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
On Sun, Dec 13, 2009 at 12:03 PM, Dennis Clark <boomf...@gmail.com> wrote:
> Race conditions caused by directly invoking application or session
> initialization code often require more thought than simply throwing a cflock
> around the call. I decided to write a blog entry to explain:
On Sun, Dec 13, 2009 at 12:03 PM, Dennis Clark <boomf...@gmail.com> wrote:
> Race conditions caused by directly invoking application or session
> initialization code often require more thought than simply throwing a cflock
> around the call. I decided to write a blog entry to explain:
> On Sat, Dec 12, 2009 at 9:25 PM, Raymond Camden <rcam...@gmail.com> wrote:
>> You don't need to lock if you let them run "normally." If you run the
>> methods manually (many people will add a call to onApplicationStart
>> inside their onRequestStart if a URL param exist) then you may need a
>> lock. Of course, you only need a lock if you actually care about a
>> race condition. 99% of the code I see in application startup just
>> initializes a set of variables.
>> On Sat, Dec 12, 2009 at 5:55 PM, Sean Corfield <seancorfi...@gmail.com>
>> wrote:
>> > On Sat, Dec 12, 2009 at 7:33 AM, Phillip Senn <phillips...@gmail.com>
>> wrote:
>> >> Do you need to lock the application scope, or is that implied in
>> >> onApplicationStart?
>> > onApplicationStart() (and onSessionStart()) are automatically
>> > single-threaded by the CFML engine (so, no, you don't need to lock).
>> > --
>> > Sean A Corfield -- (904) 302-SEAN
>> > Railo Technologies US -- http://getrailo.com/ >> > An Architect's View -- http://corfield.org/
>> > "If you're not annoying somebody, you're not really alive."
>> > -- Margaret Atwood
>> --
>> ===========================================================================
>> Raymond Camden, ColdFusion Jedi Master
>> You received this message because you are subscribed to the Google Groups
>> "Object-Oriented Programming in ColdFusion" group.
>> To post to this group, send email to coldfusionoo@googlegroups.com.
>> To unsubscribe from this group, send email to
>> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/coldfusionoo?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "Object-Oriented Programming in ColdFusion" group.
> To post to this group, send email to coldfusionoo@googlegroups.com.
> To unsubscribe from this group, send email to
> coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/coldfusionoo?hl=en.
Oh, so the problem is not in the code that you're looking at
(onApplicationStart), but the fact that you are reinitializing a
shared scope while someone else is using it another part of the
system.
I got it.
On Dec 13, 3:03 pm, Dennis Clark <boomf...@gmail.com> wrote:
> Race conditions caused by directly invoking application or session
> initialization code often require more thought than simply throwing a cflock
> around the call. I decided to write a blog entry to explain:
> On Sat, Dec 12, 2009 at 9:25 PM, Raymond Camden <rcam...@gmail.com> wrote:
> > You don't need to lock if you let them run "normally." If you run the
> > methods manually (many people will add a call to onApplicationStart
> > inside their onRequestStart if a URL param exist) then you may need a
> > lock. Of course, you only need a lock if you actually care about a
> > race condition. 99% of the code I see in application startup just
> > initializes a set of variables.
> > On Sat, Dec 12, 2009 at 5:55 PM, Sean Corfield <seancorfi...@gmail.com>
> > wrote:
> > > On Sat, Dec 12, 2009 at 7:33 AM, Phillip Senn <phillips...@gmail.com>
> > wrote:
> > >> Do you need to lock the application scope, or is that implied in
> > >> onApplicationStart?
> > > onApplicationStart() (and onSessionStart()) are automatically
> > > single-threaded by the CFML engine (so, no, you don't need to lock).
> > > --
> > > Sean A Corfield -- (904) 302-SEAN
> > > Railo Technologies US --http://getrailo.com/ > > > An Architect's View --http://corfield.org/
> > > "If you're not annoying somebody, you're not really alive."
> > > -- Margaret Atwood
> > You received this message because you are subscribed to the Google Groups
> > "Object-Oriented Programming in ColdFusion" group.
> > To post to this group, send email to coldfusionoo@googlegroups.com.
> > To unsubscribe from this group, send email to
> > coldfusionoo+unsubscribe@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/coldfusionoo?hl=en.
