CFLOCK and CFDIRECTORY

[WolfShade]

Hello, all.

If I put an exclusive CFLOCK around a CFDIRECTORY, will that prevent anything else from accessing the directory until I close the CFLOCK?

Thanks,

^_^

[Kevin_Schmidt]

It will only prevent that block of code from executing while the lock is in place.

If you have multiple places where to code to manipulate the directory is used, make sure you use a named lock.

HTH,

Kevin

[TLC-IT]

The <cflock> tag uses a named-mutex implementation.  All applications and pages must cooperatively make sure that they are conforming to whatever mutual-exclusion arrangement you have devised.  You will have to "desk check" your code.

[WolfShade]

So, for example, if I have one CFM file that has the following code:

<cflock name="dirLock" type="exclusive">

  <cffile action="write" addnewline="no" file="D:\data\text\ids\thisfile.txt" output="#thisOutputString#">

</cflock>

.. and then have another CFM file that has:

<cflock name="dirLock" type="exclusive">

  <cffile action="read" file="D:\data\text\ids\thisfile.txt" variable="dataString">

</cflock>

.. and let's say that the file in question is 3 megabytes in size.  If either one of the CFM files is accessing the directory, will that lock out the other file until the first file is done processing?

Thanks,

^_^

[Kevin_Schmidt]

Yes, make sure you add timeouts to your cflocks too.. so they don't wait forever to try to get a lock.  Of course you will want to add error handling if the locks do timeout.

[TLC-IT]

... and you are obligated to ensure that locks are released properly in all cases.  If code within a lock-section could throw an exception ...

It can be tricky.  It's easy to write the code correctly but it does take particular discipline and attention to detail...  more so than in other types of coding.

"See this bald-spot over here?  Yep, that was a synchronization problem ...  And this one, with a scar on it?  Why yes, well do I remember that bug... it was in December of 19..."

(No bald spots here ... fortunate genetics, I suppose ... but, "vivid memories?"  Oh, yes, yes, yes.)

[WolfShade]

Thank you, both, for your insight.  I have just one more question.

Hypothetically speaking, let's say there are more than one server running these files.  For sake of argument, let's say there are five servers, all with the same CFM files.

Will the CFLOCK (if all five use the same CFLOCK name) prevent only the other file on itself from accessing the directory?  Or will all five prevent other files from the other four servers from accessing the directory?

Thank you,

^_^

[TLC-IT]

A <cflock> will reliably block any other code which attempts to lock the same name, within the same scope, at the same time.

"That's it.  It locks a name within a scope.  That's it. That's all." It not matter what the code inside of the lock-protected section is doing.  What matters is that every piece of code that is "doing the same thing," or that is accessing the same shared resource in any way whatever, must be enclosed within <cflock> tags which are locking the same name within the same scope.

If there exists any code, anywhere, which touches that shared resource (a file, a variable, or whatever it may be) in any way whatever without doing so within the auspices of a correctly-named and correctly-scoped lock ... it is a most serious bug that can quite-easily escape your attempts at testing.

If you need to make sure that the shared resource is stable during your access to it, but you don't mind if other pieces of code are examining it at the same time as you, then use a "read" lock.  But if you intend to modify the shared resource in any way, your lock must be "exclusive."  You must be mindful of the possibility of deadlock, or, separately, lock-timeout.

To write this kind of code correctly, first familiarize yourself ("Google it...") with the issues of so-called "mutual exclusion," then carefully plan your locking strategy and hand-inspect the completed code to make certain that it complies with your strategy.