Jakarta Concurrency
This chapter describes the background to the introduction of Jakarta Concurrency and its functionality.
1. Overview
It is recommended that application servers do not use concurrency APIs such as Thread, Timer, and ExecutorService provided in Java SE in the EJB or a web component. It is assumed that Jakarta EE application components such as Servlets and EJB are executed in a thread managed by an application server. It is also assumed that the functions provided in a container are executed in the same thread.
For these reasons, application components cannot safely use Jakarta EE services in a thread that is not managed by a container. Furthermore, if resources are used in a thread that is not managed by a container, potential issues regarding usability, security, reliability, and scalability can occur in Jakarta EE.
To solve problems that occur in unmanaged threads, Jakarta Concurrency specification, which extended the concurrency utilities of Java SE, is provided.
This technology guarantees the execution of applications without damaging the integrity of containers in the Jakarta EE environment.
2. Managed Task
In order to reduce consumption of unnecessary resources, a container must pool resources and manage life cycles. However, if asynchronous tasks are executed in a component by using the concurrency APIs provided in Java SE, then the container cannot manage the resources as it cannot recognize them.
As a result, this specification has defined managed tasks by expanding on the tasks defined in java.utill.concurrent in the existing Java SE. This allows a container to manage general tasks as managed tasks, and maintains the execution context when a task is executed asynchronously.
3. Container Thread Context
In the Jakarta EE environment, a container contains the context information of each service when a service is executed.
If the Java SE’s concurrency API is used in a component, then to maintain the context information of a service in a thread where a new container has been created, application developers must propagate the context in the following method.
-
Store the container context of the application component thread.
-
Determine which container context to store and propagate.
-
Apply the container context in the newly created thread.
-
Restore the context of the original component thread.
By using the above method, a task can be executed while maintaining the context of Java SE’s concurrency API. However, if the Jakarta Concurrency services is used, user-defined tasks can be easily sent to managed objects. This allows the context to be automatically maintained and restored.
When Executing a Task by Maintaining the Context
-
java.util.concurrent.Callable
-
call()
-
-
java.lang.Runnable
-
run()
-
-
jakarta.enterprise.concurrent.ManagedTaskListener
-
taskAborted
-
taskSubmitted
-
taskStarting
-
-
jakarta.enterprise.concurrent.ManagedTaskListener
-
taskAborted
-
taskSubmitted
-
taskStarting
-
-
jakarta.enterprise.concurrent.Trigger
-
getNextRuntime()
-
skipRun()
-