Java Magazine - July/August 2012

//enterprise java /

Threading and Concurrency
Java EE 6 reflects that centralized management of scarce resources
is becoming more important.
ADAM BIEN

From the beginning, application servers were designed to provide shared resources to multiple applications at the same time. Scarce resources, such as CPU time, file systems, or RAM, are supposed to be shared between applications. Fair resource sharing, however, requires some cooperation from the deployed applications.

One of the programming restrictions introduced with the Enterprise JavaBeans (EJB) 1.0 specification was “An enterprise bean is not allowed to start new threads or attempt to terminate the running thread” (page 117). Current restrictions on popular cloud platforms are similar to the Java EE programming model. You could argue that application servers have been cloud-ready since the advent of EJB 1.0 in 1998. Note: Download the source code for the sample application described in this article.

Forbidden Threads

Without explaining why, EJB 1.0
prohibited the direct use of
threads and synchronization prim-
itives. The EJB 3. 1 specification
is even stricter: “The enterprise
bean must not attempt to man-
age 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.”
The EJB 3. 1 speci-
fication explains the
reason behind the
increased restriction:
“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” (page 599).

In practice, application servers can easily prevent direct Thread manipulation by activating the SecurityManager. In the

java.lang. Thread constructor, the SecurityManager is asked for permission. However, most application servers operate without SecurityManager, so applications can easily violate the restrictions without any consequences.

In addition, the statement “Allowing the enterprise bean to manage threads would decrease the container’s ability to properly manage the runtime environment” is way too mild. The uncontrolled creation of threads affects not only scalability and performance but also robustness. Each thread consumes memory. Having too many threads eventually leads to OutOfMemoryError occurrences and not only affects the stability of the application that starts the threads, but can crash the entire application server and all the deployed applications.

On the other hand, the appli-
cation server reuses threads
from managed and monitored
pools. You can securely prevent
OutOfMemoryError occurrences by
regularly performing stress tests,
as described in “Stress Testing
Java EE 6 Applications,” and
using the results to configure the
application server thread pools. A
properly configured thread pool
will reject new requests to prevent
server overloading.