From the course: Java EE: Concurrency and Multithreading

Need for Java EE concurrency

From the course: Java EE: Concurrency and Multithreading

Start my 1-month free trial

Need for Java EE concurrency

“

- [Instructor] Now that we have laid down a foundation for the Java Standard Edition platform concurrency APIs, it's time to move on to the Java Enterprise Edition concurrency utilities, but the first basic question that should come to mind is, why do we need a separate API? We already know that a certain API's under the Standard Edition platform, why can't we just use them and integrate into the Enterprise application? Yeah, that's a very valid question and let's understand why. Every Java Enterprise application always works within an application server, the underlying container, and these containers provide runtime support for application components like Enterprise Java Beans and servlets. They provide a layer between the application component code and the platform services and resources. Very often, Java Enterprise servers provide central resource management, resources like JDBC data sources, transaction management, connection pooling, et cetera. These resources are centrally managed so that the other application components do not end up consuming unnecessary resources. So, there is this managed environment that is set up by the container, and in such an environment, application integrity is very important. So, when you have a managed environment like that, applications can coexist without causing any harm to the overall system. So, when you have a thread running a job in an enterprise environment, the container is going to expect that the thread gets all the container's supplied objects and resources to run the asynchronous task. Another thing is, the thread is required to access the Standard Enterprise Edition services, like Java Messaging Service, Enterprise Java Beans, et cetera. And for this, it is required that the contextual information of the container is provided to the thread. Contextual information is Java naming and directory interface naming, class loader information, security context. It is very important that the container propagates this information to all the threads executing the jobs for you. Now we've seen that there's a managed environment, the central resource management, this contextual information, et cetera, which means, if we try to create our own threads using the Java Standard Edition platform, then the container will not be aware or wouldn't have any knowledge of these thread resources. And in that case, it will be problem because it will not be able to provide correctly the contextual information needed to access the Java Enterprise services. That's why when you have an Enterprise Java Bean or a servlet, they are not able to reliably use the standard EE services from a thread which is not managed by the container. So, now it'll be wiser for the container to have those threads managed instead of us creating them ourselves, and that's exactly why the Java Enterprise Edition concurrency utilities were born. So, this API was released as a Java specification request 236 in Java EE 7, which enabled enterprise applications to submit asynchronous tasks. So, the goal was to define and use centralized, manageable objects inside the Java Enterprise server. Now, the Java Enterprise concurrency API is actually an extension to the java.util.concurrent APIs, which is a Standard Edition platform, and it was done so that there's a smooth migration path from the SE to the EE. So, these new concurrency APIs that are a part of the Java Enterprise platform now become the resources of the container, so everything is going to managed by the container now. These concurrency APIs will help you to manage and monitor the lifecycle of all the asynchronous operations in your Java Enterprise application component. So, it could be an EJB, it could be a servlet, it could be a RESTful bean. And when you have all the threads and all these resources managed by the container, then the threads which are executing the tasks will be provided with the correct contextual information of the container. In the next video, we will look at the API hierarchy, the main APIs that we're going to take a look at in this course.

Contents