For a CFDJ article on the Singleton Design Pattern I did something similar
but instead of caching CFCs in the Application scope per each user session
I am using a persistant CFC instance which I am storing in the Server
scope. In preperation for the article I asked Rob Bilson and Ray Camden if
they saw any inherent flaw in my use of the server scope. And while this
isnt something either would have done or conceived of, it didn't seem to be
a particularly risky proposition.
Here is my Application Mgr "Base Class" CFC:
<cfcomponent displayname="ApplicationMgr">
<!---
App.* Stores Private Application Data
Accesible only within CFC
--->
<cfparam name="App" type="struct" default="#structnew()#">
<cfset App.name = "AbstractApp">
<cfset App.clientManagement = "Yes">
<cfset App.clientStorage = "registry">
<cfset App.setClientCookies = "Yes">
<cfset App.sessionManagement = "No">
<cfset App.sessionTimeout = CreateTimeSpan(0, 2, 0, 0)>
<cfset App.ApplicationTimeout = CreateTimeSpan(0, 2, 0, 0)>
<cfset App.setDomainCookies = "Yes">
<!---
My.* Stores Public Application Data
Accesible via GetValue("VarName")
--->
<cfparam name="My" type="struct" default="#structnew()#">
<cfset My.InstanceID = createUUID()>
<cffunction name="getInstance" access="public"
returntype="struct" output="no">
<cfif NOT IsDefined("Server.ao__ApplicationMgr_AppObj") OR
NOT IsStruct(Server.ao__ApplicationMgr_AppObj)>
<cflock timeout="10" throwontimeout="No"
type="EXCLUSIVE" scope="SERVER">
<cfif NOT IsDefined("Server.ao__ApplicationMgr_AppObj") OR
NOT IsStruct(Server.ao__ApplicationMgr_AppObj)>
<cfset Server.ao__ApplicationMgr_AppObj = this>
</cfif>
</cflock>
</cfif>
<cfreturn Server.ao__ApplicationMgr_AppObj>
</cffunction>
<cffunction name="Execute" access="public" output="Yes">
<cfapplication
name="#App.name#"
clientManagement="#App.clientManagement#"
clientStorage="#App.clientStorage#"
setClientCookies="#App.setClientCookies#"
sessionManagement="#App.sessionManagement#"
sessionTimeout="#App.sessionTimeout#"
applicationTimeout="#App.applicationTimeout#"
setDomainCookies="#App.setDomainCookies#">
</cffunction>
<!--- GET THE VALUE OF A PROPERTY --->
<cffunction name="getValue" access="public" output="false">
<cfargument name="name" required="Yes" type="string">
<cfif IsDefined("My.#arguments.name#")>
<cfreturn My[arguments.name]>
</cfif>
</cffunction>
</cfcomponent>
In the article I sub-class this for two different apps. Here is my Application.cfm
file for a particular App:
<cfset Quote = CreateObject("component", "com.mycompany.Quote.QuoteAppMgr")>
<cfset Quote = Quote.getInstance()>
<cfset Billing = CreateObject("component", "com.mycompany.Billing.BillingAppMgr")>
<cfset Billing = Billing.getInstance()>
<cfset Billing.Execute()>
Now the app can utilize Quote.xxxx and Billing.xxxx anywhere to access what normally
would be Application or Request Scope variables.
Billing.Execute() outputs the <CFAPPLICATION> tag.
You can check out the article here:
http://www.sys-con.com/coldfusion/articlea.cfm?id=624
And all the code here: http://www.sys-con.com/coldfusion/source.cfm?id=624
Obviously this is just a starting point but I think it is pretty
interesting idea.
Brendan
"Nathan Dintenfass" <[EMAIL PROTECTED]>@cfczone.org on 07/25/2003
01:13:10 PM
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
cc:
Subject: RE: [CFCDev] CFC Caching
I have been using application-cached CFCs for a while now with great
success. You are certainly saving some overhead of instantiation -- which
can be the most expensive part of using CFCs. I have not experienced any
problems, but the apps I've tried this in aren't under heavy load. I think
Sean talked about using this technique in Macromedia.com, however, which
certainly gets fairly heavy traffic.
The obvious warning is to look out for the page context but, but if you are
following the rules of encapsulation so often preached on this list you
shouldn't run into that (and should one day soon not have to even think
about that either).
In some of my recent apps I have a series of "services" which are CFCs
cached in the application scope -- at instantiation I usually pass in a DSN
name if they are doing queries. In some circumstances I am passing an
instance of one service to another service at instantiation -- this way I
can preserve encapsulation while taking advantage of one service inside
another service.
I've also had luck caching CFCs in the session scope. In particular, I've
taken to having a "session.messenger" CFC which basically keeps an array of
different "messages" I want to show to the user. Then, in my validation
scripts I can do something like:
session.messenger.newError(errorMesage);
And then grab those messages to show to the user in my page wrapper
(session.messenger.getMessages())
Obviously, using session-cached CFCs won't work in a cluster (absent sticky
sessions).
In theory, the only locking issues you should have are race conditions --
but, it sounds like if you're just doing some queries that should not be an
issue.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Michael Dinowitz
> Sent: Friday, July 25, 2003 9:51 AM
> To: [EMAIL PROTECTED]
> Subject: [CFCDev] CFC Caching
>
>
> I'm playing around with a new methodology and part of it involves
> caching some
> CFCs into the application scope. I see no problem doing so but
> others may know
> more than I in this. Is there a savings in doing this? Any
> overhead or problems
> that I don't foresee?
>
> The first thing I do is check if its in the application scope and
> if not, create
> and initialize it. Then I just use it when needed. There's no
> locking going on
> as the CFC is only doing queries and related operations (no
> insert or update
> operations).
>
> Michael Dinowitz
> Finding technical solutions to the problems you didn't know you had yet
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
