Hi Barry
Locking withing the method would be preferable
1. less code to write
2. more secure - you don't have to worry if every call to the function has been locked properly
3. Faster - as the locking takes place only for the critical parts of the function, rather than locking the whole function, there is less code between the <cflock> tags, hence you can have a higher throughput of threads (each thread holds the lock for less time)
Finally, from my own design perspective, locking is an internal part of the objects functioning unrelated to the caller, hence the object should handle it internally
Regards
Aaron Foote:
Software Engineer and Hosting Support Telligence Pty Ltd : http://www.telligence.com.au Incorporating Austiger Hosting: http://www.austiger.com.au Email: [EMAIL PROTECTED] Phone: 1300 852 189 Fax: 02 49677266
Telligence: Working with you to succeed online
Barry Beattie wrote:
I just wanted to check (best practices 'n' all)
I writing a server-scoped singleton CFC that is stores which records are currently being edited (think of it as a "pesimistic lock registry" using a struct of structs in CFC variables memory). there's also methods for setting and deleting "locks" which will just add a struct key or remove it.
now obviously, because it's a singleton and I need to prevent RACE conditions, I'll have to CFLOCK the setting and deleting. Normally I'd do it in the call but is there anything actually *wrong* with using CFLOCK _within_ the SET and DELETE methods of the singleton?
so the choices are (1) lock the call
<cflock scope="SERVER" type="EXCLUSIVE" throwontimeout="Yes" timeout="10"> <cfset bOK = server.kernel.SetEntityLock(entity) /> </cflock>
- OR - (2) lock within the method
<cffunction name="SetEntityLock"> <cfargument name="lockData" type="struct" required="Yes" /> <cfset var bOK = false /> <cflock scope="#variables.lockScope#" type="EXCLUSIVE" throwontimeout="Yes" timeout="10"> <!--- add a struct to the "lock registry" here ---> <cfset bOK = true /> </cflock> <cfreturn bOK /> </cffunction>
thanx barry.b
---------------------------------------------------------- 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).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
-- Aaron Foote:
Software Engineer and Hosting Support Telligence Pty Ltd : http://www.telligence.com.au Incorporating Austiger Hosting: http://www.austiger.com.au Email: [EMAIL PROTECTED] Phone: 1300 852 189 Fax: 02 49677266
Telligence: Working with you to succeed online
-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005
---------------------------------------------------------- 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).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
