在JavaEE EJB / Web容器中创建线程 [英] Thread creation in JavaEE EJB/Web containers
问题描述
我现在有点困惑。虽然我遇到了在EE应用程序中进行手动线程池管理的情况，但我可以理解为什么在JavaEE容器中手动创建线程是一个坏主意。但是，当您可以将大部分EJB部署到任何一个EJB时，我不明白EJB容器和Web容器之间的区别，该容器与线程创建相关。如果在Web容器中产生线程的会话bean没有任何问题，可以通过将相同的会话bean部署到EJB容器来引起哪些问题？
这是Java EE的企业部分符合现实世界的地方。
使用企业系统的前提主要集中在围绕管理。具体将决策和配置放在容器中，而不是依赖于应用程序本身来管理这些资源。通过将资源的创建和管理从应用程序代码中分离出来，依靠容器，系统管理员就可以对这些资源进行可视化和访问，从而有可能在更高的级别调整和监视应用程序，并以常见的方式，而不是使用特定于应用程序的机制。
所以，这就是我们所处的环境，这也是驱动Java EE规范中关于什么的这些规则的一部分你可以和不能（不应该）做。
现在，servlet容器规范，更加野生西部。它没有所有这些企业管理功能（心中，许多容器暴露他们，但规范没有提及）。例如，提供静态文件是Web容器的面包和黄油功能，因此开发人员限制对所述文件的访问几乎没有意义。此外，servlet规范是在EJB规范之前的，并且被绑定到环境中，而不是根据该环境重做。
这给了你两个矛盾的规范对于特定的事情（如线程），
所以，是的，Servlet规范让你管理自己的线程池，即使在Java EE应用程序中，甚至虽然这些线程池可能与Java EE容器完全相同的JVM（因此无法管理地消耗Java EE资源）。
这最终意义在真正的世界是，是的，如果你想要的话，你可以在一个Java EE容器或一个servlet容器中来处理线程。没有一个受欢迎的容器禁止你这样做（WebSphere可能，我不使用它）。
但是，你不应该。 Java EE（特别是Java EE 6）具有机制和环绕，您可以跳过来做事情，而不是使用线程池。例如WorkManagers，JMS队列，异步会话bean，计时器作业。
在servlet应用程序中，大多数机制不存在，因此您无法利用它们，因此您使用只是Java。
在使用Java EE应用程序部署的Web应用程序中使用Just Java的后果在容器内可见。例如，您的网络应用程序将需要自己的配置变量来设置其线程池的大小，并且不能依赖该容器来管理。
最终，通常没有大的交易。 Java EE的大部分复杂性集中在许多人不使用的管理功能上。对于我自己，我使用Java EE，很少使用一个简单的WAR，我喜欢尽可能多地推送到容器中 - 让它完成它的工作。也就是说，我在Java EE容器中的WAR中运行了定制的套接字服务器，打破了每个可以想象的规则，只是因为它更容易做到。 Java EE Way并不是靠近我们想要完成的灵活性，所以我们去了Just Java，并将代码倒入了一个WAR，所以我们可以在Wild Wild West中玩，男人是男人，管理自己的线程。
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.
这篇关于在JavaEE EJB / Web容器中创建线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
