Question

We are creating a web app where we need to have concurrency for a few business cases. This application would be deployed in a tomcat container. I know that creating user defined threads in the web container is a bad idea and am trying to explore options that i have.

1. Have my multi-threaded library used as a JCA component. We are averse to using this approach because of the learning curve that might be involved.
2. I know that there’s WorkManager API’s available but i guess thats not implemented by tomcat so this option goes out.
3. I did some research and found out that CommonJ library is recommended for Tomcat. Has anyone used it?
4. Also, I see that there are ManagedExecutorService available but I am not sure how to use it and is it different from WorkManager API’s (and the commonJ library)?

Any help on this appreciated. By the way, using JMS is out of question because of deployment environment. I am inclining towards points 3 and 4 but i do not have much knowledge on it. Could someone guide pls.

Answer 1

Since you’re using Tomcat, don’t worry about it and do whatever you want. The Servlet section of Java EE makes no mention of threads etc. That’s mostly under the EJB section.

Tomcat itself doesn’t do much at all in terms of worrying about managing threads, it’s a pretty non-invasive container.

Its best to tie your threads to a ServletContextListener so that you can pay attention to the application lifecycle, and shutdown your stuff when you app shuts down, but beyond that, don’t overly concern yourself about it and use whatever you’re happy with.

Addenda –

The simple truth is Tomcat does not care, and it’s not that sophisticated. Tomcat has a thread pool for each of the HTTP listeners and that’s about the end of its level of management. Tomcat is not going to take threads from a quiet HTTP listener and dedicate them to a busy one, for example. If Tomcat was truly interested in how you create threads, it would prevent you from doing so — and it doesn’t.

That means that thread management outside of the HTTP context falls squarely on your shoulders as an implementor. Java EE exposes these kinds of facilities, and the interfaces make great reads. But the simple truth is that the theoretical capabilities espoused by the Java EE API docs, and the reality of modern implementations is far different, particularly on low end systems such as Tomcat.

Not to disparage Tomcat. Tomcat is a great piece of software. But for most of its use cases, the extra management capability simply is not necessary.

Setting up your own thread pool (using the JDK provided facilities) and working with your own thread lifecycle model will likely see you successfully through whatever project you’re working on. It’s really not a big deal.