Blog

Extending a ColdBox App's Lock Timeouts

Luis Majano March 12, 2009

Spread the word

Luis Majano

March 12, 2009

Spread the word


Share your thoughts

By default, any ColdBox app has a lock timeout of 30 seconds for their requests.  If longer running processes occur in which they do not give the lock away (for whatever reason it is) there could be a chance of the request to timeout and throw and error.  Therefore, you might be interested in maybe increasing it on high availability applications in order to allow longer running processes to finish.  In order to tweak this setting, you should open your Application's Application.cfc file.
* This only works on Application.cfc's that use inheritance. Non-inheritance Application.cfc will have to wait for ColdBox 3.0 or manually change this in the main coldbox.cfc
Once inside the file, locate the following: And add the following snippet: That's it! You use the setTimeout() method and pass in an integer that denotes the number of seconds to wait for a lock. Now, most of the time, if you have processes taking longer than 30-45 seconds, that to me is a red-flag going up. You should seriously revise your code and processes of why you want processes running for so long.

Add Your Comment

(3)

Mar 13, 2009 20:28:03 UTC

by Gabriel

One may not want processes running for too long on public facing sites. However, if you have private management type pages that may run for a long time but they work well otherwise, what's your recommendation for including those in an application? I tested a long running page and it caused a timeout error on the public facing part of the site. Is the only option to move those long running pages into their own "app" so that it doesn't interfere with the public side? Thank you, Gabriel

Mar 14, 2009 08:26:25 UTC

by Gabriel

So, I looked into the framework code and found that my timeout error was occurring because, in a development environment, I am "auto reloading" everything with each request. So the long running request caused the public side request to fail because it couldn't get a lock in the "AutoReload Tests" of coldbox.cfc. That said, I changed to a "production" environment (doesn't reload everything on every request) and the long running request did not bring down the public facing side. I think I should be ok leaving these long running pages as part of the same app as the issue does not happen with real production settings. If you'd advise otherwise, please let me know.

Mar 16, 2009 12:56:05 UTC

by Luis Majano

Yes, auto reload puts a lot of stress on the application because every request has to do exclusive locking just to make sure the app get's reloaded. Definitely use it for development only if possible. Lock timeouts and request timeouts are two different settings.

Recent Entries

12 Days of BoxLang - Day 4: TestBox

12 Days of BoxLang - Day 4: TestBox

Today we’re celebrating one of the most exciting new additions to the BoxLang ecosystem:

the TestBox BoxLang CLI Runner — a fast, native way to run your TestBox tests directly through the BoxLang Runtime. ⚡

No server required. No CommandBox needed. Just pure, ultra-fast BoxLang-powered testing from the command lineon Windows, Mac, and Linux.

If you’re building modern applications with BoxLang — web apps, CLIs, serverless functions, Android apps, or OS-level utilities — this new feature gives you a unified, flexible testing workflow you can run anywhere.

Victor Campos
Victor Campos
December 13, 2025
12 days of BoxLang - Day 3: SocketBox!

12 days of BoxLang - Day 3: SocketBox!

As BoxLang continues evolving into a modern, high-performance, JVM-based runtime, real-time communication becomes essential for the applications we all want to build: dashboards, collaboration tools, notifications, live feeds, multiplayer features, and more.

That’s where SocketBox steps in — the WebSocket upgrade listener built to work seamlessly with CommandBox and the BoxLang MiniServer. ⚡

Today, for Day 3, we’re highlighting how SocketBox supercharges BoxLang development by giving you fast, flexible, and framework-agnostic WebSocket capabilities.

Maria Jose Herrera
Maria Jose Herrera
December 12, 2025
12 Days of BoxLang - Day 2: CommandBox

12 Days of BoxLang - Day 2: CommandBox

BoxLang + CommandBox: The Enterprise Engine Behind Your Deployments

For Day 2 of our 12 Days of Christmas series, we’re diving into one of the most powerful parts of the BoxLang ecosystem: CommandBox the defacto enterprise servlet deployment platform for BoxLang.

If BoxLang is the language powering your applications, CommandBox is the engine room behind it all. ⚙️

Victor Campos
Victor Campos
December 11, 2025