how can i test the cflock functionality for throwontimeout

I think you are misunderstanding what the lock timeout is for. It's not about how long the code in the lock takes; it's about how long the lock will wait to get the lock. You can't test it with only one thread. This might clear things up: https://trycf.com/gist/4f01eeadddde47774c739074ded446d5/lucee5?theme=monokai Here I'm using threads in one request as I want it to be stand-alone, but they could be separate requests, as locks are server-wide.

Thanks, so the cflock work only when we use threads, else they have no relevance because if we are using cfstandard edition adn i think it has a limit of 20 threads a6 a time and we are using cflock exclusive for login, does it have to wrapped with cfthread of it can be without cflock

@gsr It isn't just threads in a single request. Each request has one or more threads, so if you have multiple concurrent users in your Web application, each of those are separate threads and the locking will potentially interact between those per-request threads.

so you are saying we just cannot remove cflock like this, if its there, removing it might effect the concurrency of the login

Don't be too literal about my usage of threads there. A request is a thread too. Actually if you open your own trycf gist in two separate browsers, and run both at the same time, you'll see the second one will error-out

right

To answer your question though: no, never remove code from your app you don't understand. The person who put it in the probably did understand it, and it's there for a reason. It's your job to do the investigation to understand why the code is the way it is.

@Adam Cameron Being old and scarred and crotchety like you, I have horror stories about that sort of situation. Top of mind was a conversation I had with a junior developer whose work got handed to me right before he was shown the door, who told me something along the lines of "you'll probably find bugs in there but some of them are there on purpose to make it work". At which point, my eyes rolled back in my head and the conversation was largely over.

Blimey. And yeah, I think we've all been bitten by "ah, this code is wrong / old / obsolete, gonna get rid" only to find out the hard way that it was right / current / in use.

In was just going to write, ahh then falls in the wonderful REQUIRED TESTS and multi-stage deployments (dev, test, preprod, prod...) before code hits the real world use.... 🙂

(and for additional context, conversation referenced above was about 35 years ago and said junior developer was being "exited" because they had been reporting for several weeks their work on that particular code was "finished" which turned out meant they had written it but hadn't yet been arsed to try to compile it, let alone test it. seemed like it just wasn't going to work out in the long run...)