ColdFusion Design Patterns site - Singleton

[Sean Corfield]

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

[Kevan Stannard]

I'll fix that thread safe issue, thanks.

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.

Thanks

2009/12/11 Sean Corfield <seanco...@gmail.com>

--

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 coldfu...@googlegroups.com.
To unsubscribe from this group, send email to coldfusionoo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/coldfusionoo?hl=en.

[Sean Corfield]

On Fri, Dec 11, 2009 at 12:41 AM, Kevan Stannard
<kevans...@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).

[Kevan Stannard]

Yep, I see what you mean. I'll rework it a bit, thanks.

2009/12/11 Sean Corfield <seanco...@gmail.com>

[Patrick Santora]

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")>


        <cfset application.singleton = createObject("component","SingletonA").init()>


    </cfif>
    <cfreturn application.singleton>


</cffunction>

</cfcomponent>

-Pat

[Patrick Santora]

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.

-Pat

[Sean Corfield]

On Fri, Dec 11, 2009 at 7:47 AM, Patrick Santora <patw...@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!

[Patrick Santora]

Ah of course. Sounds like a yes as long as the lock is in place.

[Kevan Stannard]

I've updated the Singleton page 

http://www.coldfusiondesignpatterns.org/wiki/Singleton

Couple of changes

* 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?

[Kevan Stannard]

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 <patw...@gmail.com>

[Pat Santora]

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

[Pat Santora]

Amended to the email I just sent...

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 <kevans...@gmail.com> wrote:

[Sean Corfield]

That works for me.

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

[Phillip Senn]

Do you need to lock the application scope, or is that implied in onApplicationStart?

[Sean Corfield]

On Sat, Dec 12, 2009 at 7:33 AM, Phillip Senn <phill...@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).

[Raymond Camden]

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.

--
===========================================================================
Raymond Camden, ColdFusion Jedi Master

Email : r...@camdenfamily.com
Blog : www.coldfusionjedi.com
AOL IM : cfjedimaster

Keep up to date with the community: http://www.coldfusionbloggers.org

[Dennis Clark]

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:

Boomerang Fish: ColdFusion shared scopes and race conditions

-- Dennis

[Sean Corfield]

Brilliant post! Should be required reading for every CFer!

[Patrick Santora]

Great post. I love how stories can help get a point across!

On Sun, Dec 13, 2009 at 12:03 PM, Dennis Clark <boom...@gmail.com> wrote:

[Phillip Senn]

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:
>
> Boomerang Fish: ColdFusion shared scopes and race

> conditions<http://blog.bullamakanka.net/2009/12/coldfusion-shared-scopes-and-rac...>

>
> -- Dennis
>
>
>
> 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
>
> > Email    : r...@camdenfamily.com
> > Blog      :www.coldfusionjedi.com
> > AOL IM : cfjedimaster
>
> > Keep up to date with the community:http://www.coldfusionbloggers.org
>
> > --
>
> > 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 coldfu...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > coldfusionoo...@googlegroups.com<coldfusionoo%2Bunsubscribe@google groups.com>
> > .