I read in Adam Bien’s JavaEE night hacks book that while thread creation is prohibited on EJB containers, this is not the case for web containers. He actually creates a thread pool executor in his x-ray probe which runs on Tomcat.
I’m a little confused now. While I faced situations in which I had to do manual thread-pool management in an EE app, I can somehow understand why it would be a bad idea to manually create threads in a JavaEE container. However, I don’t understand the difference between an EJB container and a web container respecting thread creation when you can deploy a great portion of EJBs to either one. If there is nothing wrong with a session bean spawning threads in a web container, what issue could be caused by deploying the same session bean to an EJB container?
This is where the “Enterprise” part of Java EE meets the real world.
The premise of using an “Enterprise” system is mostly centered around management. Specifically ceding decisions and configuration to the container rather than relying on the application itself to manage these resources. By separating the creation and management of resources from the application code and relying on the container, the system administrator then have visibility and access to those resources and thus have the potential to tune and monitor the applications at a higher level, and in a common way, than using application specific mechanisms for this.
So, that’s the environment we’re in and that’s part of what drives these “rules” of the Java EE specification about what you can and can’t (shouldn’t) do.
Now, the servlet container spec, is more wild west. It does not have all of these “Enterprise” management features (mind, many containers expose them, but the spec doesn’t mention them). For example, serving static files is a bread and butter capability of a web container, so it would hardly make sense to limit access to said files by the developer. Plus, the servlet specification came before the EJB spec and was bolted in to the environment rather than redone in the light of that environment.
That gives you two “contradictory” specifications in terms of specific things (like threads).
So, yes, the Servlet spec “lets you” manage your own thread pools, even in a Java EE app, even though those thread pools will likely be in the exact same JVM (and thus “unmanageably” consuming Java EE resources) as the Java EE container.
What this ends up meaning in the real world is that, yes, if you wanted, you could spool up threads and such within a Java EE container, or in a servlet container. None of the popular container prohibit you from doing this (WebSphere might, I don’t use it).
But, you shouldn’t. Java EE (especially Java EE 6) has mechanisms and hoops you can jump through to do things in stead of using thread pools. Things like WorkManagers, JMS queues, Asynchronous Session beans, Timer jobs.
In a servlet app, most of these mechanisms don’t exist, so you can’t leverage them, and thus you use “just Java” instead.
The ramifications of using “Just Java” in a web app deployed with a Java EE app is visibility within the container. Your web app will need its own configuration variable to set up the size of its thread pool, for example, and can’t rely on the container to manage that.
In the end, it’s typically No Big Deal. Most of the complexity of Java EE is centered around management capabilities that many folks don’t use. For myself, I use Java EE and rarely use a plain ol WAR, I like to push as much in to the container as I can — let it do its job. That said, I have custom socket servers running in WARs in Java EE containers, breaking every rule imaginable, simply because it’s been far easier to do. The “Java EE Way” wasn’t any where near flexible enough for what we wanted done, so we went “Just Java” and poured the code in to a WAR so we could play in the Wild Wild West, where Men were Men and managed their own threads.