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]
