Hi Jeff, I should have been clearer in my explanation. In my application.cfm (I'm using 6.1) I use structkeyexists to ensure that my Dao is created only once and Initialise it with the dsn. As my Dao has its own variables.dsn it's no longer stateless.
At the moment I'm not concerned about locking access to the Dao itself (although should I be?) Instead, I'm wondering whether I should lock access to variables.dsn when it called from other Dao method. i.e myDao.SelectX, myDao.DeleteX etc. As variables.dsn is effectively read-only I'm thinking no, but could very easily be wrong.
I hope I was clearer and that I didn't misunderstand you're answer.
Cheers, Pete (aka lad4bear)
----Original Message Follows----
From: Jeff Anderson <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: [CFCDev] CFC's and locking
Date: Sat, 28 May 2005 10:50:59 -0400
Peter,
> Do I have to worry about locking / race conditions?
According to the CFMX7 documentation (if you are using it), you can place
your DAO instantiation code within the OnApplicationStart method within
Application.cfc and not have to worry about locking.
If not using CFMX7 then you should put a lock around that code and also put
conditional logic in ther to instantiate it only once (ie StructKeyExists
and the such).
> And would it be more efficient to pass the dsn into each data-access
> method
Why would it be more efficient to do something many times instead of only
having to do it once?
My $.02
Jeff
On 5/28/05, Peter H <[EMAIL PROTECTED]> wrote:
>
> Hi guys,
>
> I create a Dao and place it in the application scope when the app first
> loads. The init method for my Dao is as follows:
>
> <cfcomponent displayname="MyDAO">
>
> <cfset variables.dsn = '' />
>
> <cffunction name= "Init" access="public" returntype="MyDAO"
> output="false">
> <cfargument name="dsn" type="string" required="true">
> <cfset variables.dsn = arguments.dsn />
>
> <cfreturn this />
> </cffunction>
>
> Variables.dsn is written once during the init method but is read by each
> data-access method thereafter. Do I have to worry about locking / race
> conditions? And would it be more efficient to pass the dsn into each
> data-access method
>
> Cheers, Pete (aka lad4bear)
> ----------------------------------------------------------
> 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 <http://www.cfczone.org/>) and
> supported by CFXHosting (www.cfxhosting.com <http://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]<http://www.mail-archive.com/[email protected]>
--
Who wants a Gmail invite? I have 50 of them
http://nectaar.i989.net/ - Coming Soon
----------------------------------------------------------
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]
