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:239137 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=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
