One issue that has not been discussed in this chapter is that of simultaneous read and write access to certain variables with persistent scope. Session, application, and server variables are not protected from simultaneous read/write access. Therefore, you should always use the CFLOCK tag when reading and writing to these variable scopes. If these variables are not protected, or locked, during read/write access, it is possible that several requests, or threads, to read and write to these variables could occur at the same time. This could result in corrupting the data being written or read, or possibly hanging the ColdFusion server.
For example, say you have an application variable applicaton MyQuery set in your Application. cfm template and it stores a query recordset. Person A logs on at the exact same time as Person B. Both of their’ clients request the App1; cat; on’, cfm femplate at the same time and attempt to write the results of a query to appllcatlon, MyQueryat the same time. Because these variables are not protected, the results cannot be predicted and could b: copted To prevent this, use the CFLOCK tag as described in this section.
Understanding the’ CFLOCK Tag
The CFLOCKtag has several attributes. These-attributes are described in detail in the following list.
NAME Although this attribute is not required, it is highly recommended that you use. The name should reference the variable-scope that you are locking.
For session variables you should use ses s ion, sessionID.
For application variables you should use application. application Name.
For server variables you should use server.
If two CFLOCKtags share the same name, then only one tag can be accessed at a access problems. or example, if application. test is set in one template, but no CFLOCKname is specified, ColdFusion will automatically generate a random name to lock the code. But say that in a second template someone is trying to read application. test
and the lock around that code has no NAMEattribute as well. ColdFusion will generate a unique name, but it will not be the same name that locks the write access to application. test in the first template. So you could have one user writing to the variable and another user reading the variable at the same time. This can cause the server to hang, or incorrect data to be written to the variable.
TYPE The two options are ReadOnly and Exclusive. The default type, if not specified, is Exclusive.
An exclusve lock should always be used when you are writing data to one of these variables. This lock only allows one request to process at a time. All other requests to read or write must wait until the block of code has been unlocked. The disadvantage to using this lock is that it decreases performance. Because all requests must wait in line, processing of templates slows down. A ReadOn1y lock allows more than one request to access the block of code inside the CFLOCKtag. Because requests do not have to wait, this option is faster. But, if an Excusive lock has already locked the code, then the Read on’ lock will have to wait.
TIMEOUT TIMEOUT is required and specified in seconds. If a CFLOCKblock of code is currently locked, this attribute specifies the number of seconds that the next request to the same CFLOCKmust wait before the current lock times out.
THROWONTIMEOUT THROWONTIMEOisUnTot required but will default to Yes. Yes means that if the TIMEOUTexpires, then CF will produce an error. Using the CFTRY and CFCATCH tags can catch the error. If Nois specified, then the template will continue to be processed and the code in the CFLOCK tags will be skipped.