Implementing concurrency in Java EE Web application

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.

Answer 2

There are a couple of options. Regardless container restrictions that might or might not be in place, spawning individual threads on demand is nearly always a bad idea. It's not that this wouldn't work in a Servlet environment, but the number of threads you can potentially create might get completely out of hand.

The simplest solution to go with is a plain old Java SE thread pool via a normal executer service. Start the pool in a Servlet listener and provide access to it via some static variable. Not overly pretty, but it gets the job done. Depending on your exact use case this might actually be the best solution (if your use case is pretty low-level).

Another option is to add OpenEJB to your war, and then take advantage of the @Asynchronous annotation.

Yet another option, is to realize that one typically uses Tomcat if the business requirements are extremely simple or low-level. That's pretty much the entire point of using something as bare bone a Tomcat. As soon as you find yourself in need of adding (tons of) libraries, you might have outgrown Tomcat and might be better of using a server that already has the functionality you need (in this case asynchronous execution). Examples are TomEE, GlassFish, Resin, JBoss AS, Geronimo, etc.