Why Are Custom Threads Discouraged in Java EE Containers?

Why the Discouragement of Spawning Threads in Java EE Containers

In Java EE development, spawning custom threads within the container is generally discouraged. Understanding the rationale behind this prohibition helps clarify optimal development practices.

Rationale

Java EE containers tightly manage and monitor resources within their environment. Creating custom threads disrupts this management, as they lack access to the thread-specific context essential for accessing JNDI resources like JMS Connection Factories and Datasources.

Alternative Approaches

Despite the need for asynchronous tasks like mail distribution and cleanup jobs, there are appropriate ways to achieve this within Java EE containers:

• Commonj WorkManager (for WebSphere and WebLogic): This provides a managed and monitored mechanism for spawning threads with access to the required context.
• Java EE Connector Architecture (JCA): JCA allows integration with external resource adapters, providing an interface for managing scheduled tasks or event processing.
• Message-Driven Beans (MDBs): MDBs serve as asynchronous event listeners, offering a container-managed solution for message processing.
• Asynchronous Servlets: Introduced in Java EE 6, asynchronous servlets enable processing of long-running tasks without blocking the request thread.

Evolution of Best Practices

Note that the discouragement of spawning threads in Java EE containers was more relevant in earlier versions (circa 2009). Advancements in Java EE have since improved support for asynchronous processing and managed thread pools. However, understanding the underlying reasons for the historical discouragement remains valuable for comprehension and adherence to recommended development practices.

The above is the detailed content of Why Are Custom Threads Discouraged in Java EE Containers?. For more information, please follow other related articles on the PHP Chinese website!