Adam Bien の JavaEE night hacks book で、EJB コンテナーではスレッドの作成が禁止されていますが、これは Web コンテナーには当てはまらないと読みました。彼は実際に、Tomcat で実行される X 線プローブでスレッド プール エグゼキューターを作成します。
私は今少し混乱しています。EE アプリでスレッドプールを手動で管理しなければならない状況に直面しましたが、JavaEE コンテナーで手動でスレッドを作成することがなぜ悪い考えなのか、なんとなく理解できました。ただし、EJB コンテナーと Web コンテナーのどちらにも大部分の EJB をデプロイできる場合、スレッドの作成に関しては違いがわかりません。セッション Bean が Web コンテナーでスレッドを生成することに問題がない場合、同じセッション Bean を EJB コンテナーにデプロイすると、どのような問題が発生する可能性がありますか?
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.
EJBs are server-managed. Management means i.e. dependency injection. If you spawn a thread from a class using annotations, server will be unable to handle them (do @PostConstruct, inject references etc.).
EJB は常に EJB コンテナーで実行されるため、EJB でスレッドを手動で作成しないでください。WARファイル(Webモジュール)としてのパッケージであっても、EJBコンテナ内で実行され、スレッド作成に関して同様の制限があります。
ただし、サーブレットとフィルターは Web コンテナーで実行され、手動で管理される独自のスレッド プールを持つことを禁止するものは何もありません。