Chris Dempsey wrote:
Barry,
You could also provide an optional boolean argument in your method that says whether or not the lock is held. If true, do not lock within the method, assume it is locked externally. If false, lock within the method. Have it default to false.
This way, if the caller needs to call the method a few hundred times, they can lock it once outside the loop, rather than locking and unlocking a few hundred times within the method.
HTH,
Chris
For the sake of maintainability, I'd keep the lock within the CFC entirely - if you change how you lock or change the CFC - you don't have to update code anywhere. The lock is obtained for you within the CFC.
As I pointed out in my first post, you don't want to have get a ton of locks repeatedly if your caller is going to multiple calls subsequently. I offer a solution in quasi-code:
setEntity: public {
argument: struct of entity to set
<lock>
doSetEntity()
</lock>
}setEntities: public {
argument: struct of struct (or array of structs) of entities to set etc.
<lock>
<loop> over passed argument:
doSetEntity()
</loop>
</lock>
}doSetEntity: private {
NO LOCK as it obtained in the calling function
DO CODE to set entity
}This way you have a way to set a single entity and a multiple entity while keeping the locks internal (which is really locking a CFC instance variable - so again I don't see a reason to lock the entire server scope).
HTH, .Peter
-- Peter J. Farrell :: Maestro Publishing
blog :: http://blog.maestropublishing.com email :: [EMAIL PROTECTED] phone :: 651-204-0513
If you only knew the power of the Dark Side --
---------------------------------------------------------- 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]
