Use of <cflock> or the script equivalent ('lock') creates a variable 'cflock'
1) This is inconsistent with ACF (minor complaint - the fields in this struct could be very useful)
2) This variable is created in 'variables' scope, so it's a potential concurrency problem in CFCs
To avoid concurrency risk, it appears that we need to update all CFC methods which use <CFLock> or 'lock' to add a 'var' declaration for 'cflock' - In our codebase, this is a significant project and this won't completely resolve the conflicts, since locks can be nested
1) remove the variable to restore ACF compatibility
2) add an optional attribute to <CFLock> so the results variable can be named (and don't create/update it unless this attribute is provided)
Exposure appears to be minimal, since we were able to use StructClear(cflock) within the lock block... which seems to indicate that this struct does not contain anything critical to the functioning of the lock.. however, concurrent updates to Map objects can be problematic, so there's a non-zero chance of mayhem, especially if someone writes code which uses the values (or, worse, tries to iterate over the members)
The following code demonstrates the stray variable creation - when run on ACF, the 'IsDefined' result is NO/false - on Lucee, it's YES/true:
lock type="exclusive" timeout="10" name="kilroy"
WriteOutput("got the lock<br />");
CentOS 7 (VirtualBox VM, Windows 10 host), 4GB
I've added test case for this ticket & confirmed that issue happened on latest version of lucee & 4.5.5.006. Lucee creates cflock variable when lock is executed, but ACF didn't. will have more input about the issue & he will confirm the issue.
Pull request: https://github.com/lucee/Lucee/pull/350
added support for attribute "result" that allows to set a custom variable like