无状态会话bean中的多线程？ [英] Multithreading in a stateless session bean?
问题描述
EJB 3.0规范不允许无状态会话bean的业务方法创建新线程。这是为什么？创建额外的工作线程只能进行原始计算并且永远不会调用到应用服务器中的问题是什么？
The EJB 3.0 specification does not allow a business method of a stateless session bean to create new threads. Why is that? What is wrong with creating additional worker threads that only do raw computations and never call into the app server?
说，我的会话bean实现了一个让用户上传图像的服务，并且这些商业方法对这些图像执行cpu密集型图像处理。那么即使机器有8个或更多的内核，它只能使用一个cpu内核做这个工作如果我利用第三方图像处理库，内部创建工作线程，我也将违反EJB规范，即使该库和这些线程与EJB容器无关。这似乎不正确。
Say, my session bean implements a service that lets users to upload images, and the business method does cpu-intensive image processing on these images. Then it can only use one cpu core to do this job, even if the machine has 8 or more cores? If i utilize a third party image processing library, that internally creates worker threads, i would also violate the EJB specs, even though that library and these threads have nothing to do with the EJB container at all. This does not seem right.
如果我忽略EJB规则，并且仍然创建一些工作线程来执行cpu密集处理，会发生什么？当然，这些线程不会接触到任何应用服务器对象，并且bean线程在返回之前将加入它们。仍然可以发生不好的事情。
What can happen if i ignore the EJB rules and still create some worker threads to do cpu intensive processing? Of course these threads will never touch any app server objects and the bean thread will join them before returning. Can still something bad happen?
推荐答案
EJB 3.0规范不允许无状态会话bean创建新线程。为什么是这样？
The EJB 3.0 specification does not allow a business method of a stateless session bean to create new threads. Why is that?
简短版本：不允许管理EJB的线程，因为它会损害资源管理，事务管理，安全性（技术原因），也是因为这是EJB模型不想推广的东西（哲学原因）。
Short version: managing threads from EJBs is disallowed because it would harm resource management, transaction management, security (technical reasons) and also because this is something the EJB model doesn't want to promote (philosophical reason).
EJB规范如下：
21.1.2编程限制
...
21.1.2 Programming Restrictions
...
- 企业bean不得尝试管理线程。企业bean不得尝试启动，停止，挂起或恢复线程，或者更改线程的优先级或名称。企业bean不能尝试管理线程组。
这些函数为EJB容器保留。允许企业bean管理线程会降低容器正确管理运行时环境的能力。
These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container’s ability to properly manage the runtime environment.
另请参阅
- 为什么线程创建和管理不允许？在 EJB限制常见问题
- 为什么豆不允许创建自己的线程？
- Java EE的并发实用程序
- 第2.1节容器管理与非托管线程
- Why is thread creation and management disallowed? in the EJB Restrictions FAQ
- Why are beans not allowed to create their own threads?
- Concurrency Utilities for Java EE
- Section 2.1 "Container-Managed vs. Unmanaged Threads"
- How can an EJB parallelize a long, CPU intensive process?
（...）如果我利用第三方图像流程在库内部创建工作线程，我也会违反EJB规范，即使该库和这些线程根本与EJB容器无关。这似乎不是正确的。
(...) If i utilize a third party image processing library, that internally creates worker threads, i would also violate the EJB specs, even though that library and these threads have nothing to do with the EJB container at all. This does not seem right.
我可以说，不要使用EJB，如果你不喜欢这个。 >
What can I say, don't use EJBs if you don't like this.
如果我忽略EJB规则，并且仍然创建一些工作线程来执行cpu密集处理，会发生什么？当然，这些线程不会接触到任何应用服务器对象，并且bean线程在返回之前将加入它们。还有一些不好的事情发生吗？
What can happen if i ignore the EJB rules and still create some worker threads to do cpu intensive processing? Of course these threads will never touch any app server objects and the bean thread will join them before returning. Can still something bad happen?
这些线程是否触及应用服务器对象无关紧要。规则是规则，你不想跟随他们，你是自己的，行为是未定义的。一些容器可能更容易，允许它，其他一些不会，你的应用程序不会是便携式的，但它仍然是明确禁止的。
Whether these threads are touching the app server objects or not doesn't matter. Rules are rules, you don't want to follow them, you're on your own and the behavior is undefined. Some container might be more permissive and allow it, some other won't, your application won't be portable, etc. But it's still explicitly forbidden.
如果要以标准方式生成线程，请使用WorkManager API或使用JMS。
If you want to "spawn" threads in a standard way, use the WorkManager API, or use JMS.
这篇关于无状态会话bean中的多线程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
See also
