Can I Start Threads In EJBs?
Starting threads in EJB container is clearly prohibited:
The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups. [EJB 3.1 spec, page 599]
An application server usually does not actively monitors "wild thread creation" so you can create and start as many threads you like. In fact an application server is not even capable to prevent that. However, Java SE itself is can effectively prevent starting thread by activating the SecurityManager and configuring the following permission: http://docs.oracle.com/javase/6/docs/api/java/lang/SecurityManager.html#checkAccess(java.lang.ThreadGroup)
Although this permission is not enforced per default, operations could set such rules at any time.
With default installation you could create threads, but you shouldn't. The reasons are:
- It is hard to control thread creation effectively. Each thread consumes memory. Uncontrolled creation leads to OutOfMemoryError
- Manually created threads are not monitored
- Consistency is harder to achieve--you and container are going to access a piece of code concurrently
- Throttling is harder to implement
- You are going to write superfluous code: with JavaEE it is surprisingly easy to start a managed thread. Even a JCA based solution with JavaEE 6 for thread management is relatively easy to implement. With JavaEE 7 you get even more control by injecting an ExecutorService.
Keep in mind that, Servlet Container, JMS server, EJB container, CDI container, JMX beans and JCA containers are running in the same process. Thread creation is only prohibited in the EJB spec. To make the container more robust, it should be prohibited in the whole server process. Moving the thread creation from the EJBs to e.g. Servlets is not a reasonable solution :-)
See you at Java EE Workshops at MUC Airport, particularly at the JavaEE Architectures!
Nice post; As you say in Java EE 7 there is finally a solution for parallelization needs in the form of JSR 236 ("Concurrency Utilities for Java EE"). Actually I think it's one of the most important additions in EE 7.
Posted by Gunnar on August 30, 2013 at 02:16 PM CEST #
Adam, I've always considered manual thread creation/upkeep a bad idea in EE land, but what are your thoughts on using utilities like ExecutorService and thread pooling structures that are provided by JSE?
Technically you are still creating thread, but not really managing them yourself, and can easily limit the number of thread allowed.
Posted by Nick on August 30, 2013 at 04:59 PM CEST #
this is exactly what JSR 236 is about, it allows you to retrieve an ExecutorService whose threads are managed by the container.
Posted by Gunnar on August 30, 2013 at 10:22 PM CEST #
...and my post: http://www.adam-bien.com/roller/abien/entry/injecting_an_executorservice_with_java
It is already mentioned in the post above, however JSR-235 is only available for JavaEE 7.
Thanks for reading my stuff!,
Posted by Adam Bien on September 02, 2013 at 01:45 PM CEST #
it is the same with java.io (aka "blocking io")... The spec prohibits it, but nearly every one use it either.
If you come to a project with such guy's, you will always hear the excuse "it works, so it is possible" and it is so complicated to argue to use a JCA connector for file access. (It is that easy with http://connectorz.adam-bien.com)
Also most often, the difference between Property-Files (Resource-Bundles) loaded from classpath and from directory is hard to understand and even accept for "old-fashioned" Java-Programmers. They're still access files, using java.net or manage threads by hand inside an EJB!
The JSR-342 (Java EE 7) Expert Group (namely you too) have done a great job to simplify the wording of the Spec! This is a valuable plus to the past JEE 5 Specs...
So I can really agree, that this Spec is worth reading - instead of Trial-And-Error-Programming and wondering afterwards, why the server hung up in production.
Thank you for this post! It expresses exactly what I feel :-)
Posted by Robert on September 02, 2013 at 04:46 PM CEST #
a common mistake is to start a java.util.Timer, which starts a thread.
Posted by Martin on July 21, 2016 at 01:24 PM CEST #