cflocktag/construct which you can use to ensure the integrity of shared data and it allows you to have two types of locks:
application, server, session and request.You usually do this to synchronize access to variables placed within those scopes. In all essence, scope locking is expensive as it is a BIG lock around the entire scope access. I would suggest to stick to named locks so you can have pin-point accuracy when dealing with code synchronization. Remember that locking can be expensive.
cflocktag/construct uses kernel level synchronization objects that are released automatically upon time out and/or the abnormal termination of the thread that owns them. Therefore, while processing a
cflock, the server never deadlocks for an infinite period. However, large time-outs can block request threads for long periods, and radically decrease throughput.
cflocksand inconsistent naming of locks. If you nest locks, everyone accessing the locked variables must consistently nest
cflocksin the same order. Otherwise, a deadlock can occur.