ColdFusion Singletons Revisited
My last article on singletons got a few comments on blogs and in email including how it could be improved (thanks Michael) and a few questions. I also omitted the code showing how the singletons were created and called (now added).
So here's the new improved code!
singleton.cfc
2
3 <cffunction name="init" access="public" output="false">
4 <cfset var displayname = getMetaData(this).displayname>
5
6 <cfif not isdefined("application._singletons")>
7 <cfset application._singletons = structnew()>
8 </cfif>
9 <cfif not isdefined("application._singletons.#displayname#")>
10 <cfset application._singletons[displayname] = this>
11 </cfif>
12
13 <cfreturn application._singletons[displayname]>
14 </cffunction>
15
16 <cffunction name="remove" access="public" output="false">
17 <cfset var displayname = getMetaData(this).displayname>
18
19 <cfif isdefined("application._singletons.#displayname#")>
20 <cfset structdelete(application._singletons, displayname)>
21 </cfif>
22 </cffunction>
23
24</cfcomponent>
And here hows it's setup in Application.cfm (or .cfc):
2 // function to get an instance of a singleton
3 function getInstance(name) {
4 if (not isdefined("application._singletons.#name#")) {
5 instance = createobject("component","com.classsoftware.utils.#name#").init();
6 }
7
8 return application._singletons[name];
9 }
10
11 // function to remove a singleton
12 function removeInstance(name) {
13 if (isdefined("application._singletons.#name#")) {
14 application._singletons[name].remove();
15 }
16 }
17
18 // remove instance if asked
19 if (isdefined("url.init")) {
20 removeInstance('dsn');
21 }
22</cfscript>
And how it's used on the page:
2
3 <cfquery name="myquery1" datasource="#dsn.getDSN()#">
4 select ....
5 </cfquery>
6
7 <cfquery name="myquery2" datasource="#dsn.getDSN()#">
8 select ....
9 </cfquery>
The functions getInstance and removeInstance could be placed inside a component that creates/removes singletons (a singleton factory?). However that component itself would need to be a singleton or you'd need to create it (via createobject) on every page. I'll feel it's best just to leave them as user defined functions for simplicity and performance sake.
Anther issue that came up was that you can still use createobject (or <cfinvoke>) to create other instances of the component and there seems no way of stopping this.
Well there's one way I can think of but I'm not sure if I'd actually use it in a production system, but it may be of interest to someone so here's how to do it.
ColdFusion methods can be set at run time, you can add or replace methods by assigning them to new functions like so:
2 <cfset instance.method = newmethod>
Methods can also be removed like so:
2 <cfset structdelete(instance,"method")>
So you can create a component that has a method that throws an exception (via cfabort) and then have all methods of that component call that method. You can create an instance of the component but if you call any methods you will get an error.
Applying this to our singleton component we get:
2 <cffunction name="init" access="public" output="false">
3 <cfscript>
4 var displayname = getMetaData(this).displayname;
5
6 this.invalid();
7
8 if (not isdefined("application._singletons")) {
9 application._singletons = structnew();
10 }
11 if (not isdefined("application._singletons.#displayname#")) {
12 application._singletons[displayname] = this;
13 }
14
15 return application._singletons[displayname];
16 </cfscript>
17 </cffunction>
18
19 <cffunction name="remove" access="public" output="false">
20 <cfscript>
21 var displayname = getMetaData(this).displayname;
22
23 this.invalid();
24
25 if (isdefined("application._singletons.#displayname#")) {
26 structdelete(application._singletons, displayname);
27 }
28 </cfscript>
29 </cffunction>
30
31 <cffunction name="invalid" access="public" output="false">
32 <cfabort showerror="Singletons must be created via helper functions not via create object!">
33 </cffunction>
34
35</cfcomponent>
The this.invalid(); would also needed to be added to all methods of classes than extend singleton.cfc. eg dsn.cfc in the last article.
If you then remove the method that generates the error (via structdelete) before any methods are called then the methods of the instance can be called.
Applying this to our getInstance function we get:
2 function getInstance(name) {
3 if (not isdefined("application._singletons.#name#")) {
4 instance = createobject("component","<path>..#name#");
5 structdelete(instance,"invalid");
6 instance.init();
7 }
8
9 return application._singletons[name];
10 }
That way only instances returned from our getInstance function can be used and any other instances created via created object (or other way) will throw an error when a method of that instance is called.
http://cfinternals.typepad.com/blog/2007/04/more_s...
A potential race condition exists with the above code, however it would only occur if the application variable doesn't exit and you get perfectly simultaneous requests. (ie once in a blue moon). Even if it does occur and two instances are created the same single instance is returned from the function as the application variable is returned rather than 'this'. ie the code works correctly.
For most requests (where the application variable exists) a race condition doesn't exist so adding a lock may be adversely affect performance by effectively making the code single threaded.
I also note that you added a "remove" method so the singleton could be recreated. Depending upon circumstances, the number of singletons, and how often that function is called, "blue moons" could occur more often that one might think, especially on a server under heavy load.
All in all, I think it's best to program defensively, and sinply ensure that the bug never has a chance to appear. And since the lock is inside the if test and should only occur once on object creation, the performance aspect is negligible.
I did like deleting the function reference. Neat trick. Adding function references is fun too...
Instead of deleting it wouldn't you need to do something like: instance.invalid=instance.valid; setting the "invalid" function to a safe one so initialization can proceed to completion?
If you can do the locking in such as way that it doesn't have an effect on performance then yes it should be added. It may be that later on changes to the code does make the race condition have negative side effects and these issues are very hard to debug/track down.
Glad you liked the removal of methods via structdelete still not 100% sure I'd actually use it in a production system but I'm sure it could be useful under other circumstances.
Originally I was checking to see if the method existed before calling it but once I found it wasn't needed I removed the checks to make the code simpler.
Now you might say ... just scope the class to SESSION... but not really a way to go in my books.
Generally I place the instance in the application scope that way it a singleton for the entire application. If it was placed in the session scope it would be a singleton for that users session, which can also be useful in some situations.