Adam Bien's Weblog

Friday Aug 30, 2013

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:

  1. It is hard to control thread creation effectively. Each thread consumes memory. Uncontrolled creation leads to OutOfMemoryError
  2. Manually created threads are not monitored
  3. Consistency is harder to achieve--you and container are going to access a piece of code concurrently
  4. Throttling is harder to implement
  5. 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!


Special Events: Java 8 with Java EE 7: "More Power with Less Code", 13th October, 2014 and Java EE 7: "Testing and Code Quality", 14th October, 2014

A book about rethinking Java EE Patterns

Comments:

Hi Adam,

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.

--Gunnar

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 #

Nick,

this is exactly what JSR 236 is about, it allows you to retrieve an ExecutorService whose threads are managed by the container.

--Gunnar

Posted by Gunnar on August 30, 2013 at 10:22 PM CEST #

@Gunnar,

...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!,

adam

Posted by Adam Bien on September 02, 2013 at 01:45 PM CEST #

Well...

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 :-)

Regards,
Robert

Posted by Robert on September 02, 2013 at 04:46 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
...the last 150 posts
...the last 10 comments
Links
License