Rich, Exactly... each invocation of your DAO's read() would return a separate user instance, thus you wouldn't need to lock anything.
thanks, Dave Ross http://www.d-ross.org http://www.coldspringframework.org >Dave, >I guess I did a bit too much snipping when I put my code in the email, >but I always var scope all variables. Next time I guess I'll just put >the full code in ;). > >You said that the only time I'd need a lock would be when I've got an >instance stored in shared scope. So considering that my user object in >this case is not stored in any shared scope, as long as I'm correctly >var'ing each query for the read / write operations, I won't have to >worry about any type of race conditions? > > >Rich Kroll >Application Developer > >|-----Original Message----- >|From: Dave Ross [mailto:[EMAIL PROTECTED] >|Sent: Saturday, April 29, 2006 10:42 PM >|To: CF-Talk >|Subject: Re: CF, OO, & Thread Safety >| >|Ouch, no!!! where/who told you to lock like that? You are making your >|application single-threaded by doing that! >| >|You need to var-scope the name of your query. This will make your DAO's >|read thread-safe without syncronizing the calls (making it single >|threaded). The ironic thing is that the read() method you posted ISN'T >|actually thread-safe, because you didn't local var scope the "user" >|variable, thus it becomes an instance variable of the DAO and then >could be >|overwritten by another request before your method gets a chance to >return >|it. Here's an example of thread-safe code: >| >|<cffunction name="read" access="public" output="false" >returntype="user"> >| <cfargument name="userID" type="numeric" required="yes"> >| >| <cfset var readuser = 0/> >| >| <cfquery name="readuser" datasource="#variables.dsn#"> >| -- query user >| </cfquery> >| >| <cfif readuser.recordcount eq 1> >| <cfreturn createObject("component","user").init(data)> >| <cfelse> >| <cfreturn createObject("component", "user").init()> >| </cfif> >|</cffunction> >| >|So, no, you don't need to lock anywhere. The only reason to use a lock >is >|when you have a CFC instance stored in a shared scope (e.g. application >|scope) and that CFC has properties (aka members aka instance data) >which >|you need to read and write after the object has been created. You'd >need to >|syncronize the access to those properties and thus you would use a >named >|lock for the writes. This usually isn't the case with shared-scope >objects >|like gateways, DAOs, services, etc because their methods don't modify >|instance data, thus you hardly ever need locking in an OO CFC app. >| >|Also, I'm not sure why your "gateway" would be calling a DAO. While >it's >|just naming, it would confuse me if I was looking at your code. >Gateways >|provide aggregated access to data (e.g., they return queries or similar >|datasets), while DAOs provide persistance methods (CRUD) for individual >|objects. >| >|Hope that helps... >| >|Dave Ross >|http://www.d-ross.org >|http://www.coldspringframework.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm/link=i:4:239152 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
