On 10/26/05, Andrew Scott <[EMAIL PROTECTED]> wrote:
> <cfset Application.userFactory =
> CreateObject('component','com.framework.user') />
>
> Now through the code I will make reference to it like such.
>
> <cfset Application.userFactory().AddUser(UserObject) />
> <cfset Application.userFactory().DeleteUSer(UserObject) />Those methods would need to either lock internally or you would need to surround those calls with locks. Having the named lock internal to the user object would be cleaner and safer. You need to lock when multiple threads could perform updates to the same shared data (which is the case in your example). You don't need to lock just to call methods on objects held in shared scopes if those methods don't modify instance data. > This is where I am a little unclear, I have had a look at the Mach-II > framework and it doesn't seem to do this. Except when setting the > application.userfactory in the application scope to begin with. The Mach II objects are all services - they have no internal state and therefore need no locks. Except at startup (where Mach II does a single exclusive lock around the framework initialization code). -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- 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]
