Welcome!

Java Authors: Xenia von Wedel, Elizabeth White, Liz McMillan, Ali Hussain, David Tishgart

Related Topics: Java

Java: Article

Designing Custom Multithreading Frameworks in J2EE Containers

An efficient way to improve the performance of Java apps

A custom multithreading framework is an efficient way to improve the performance of Java applications. It uses an asynchronous parallel pattern to implement the business process. However, its traditional Java thread-based implementation shouldn't be used in applications hosted in a J2EE Application Server because the threads in that framework are beyond the control of the J2EE Container. This article will discuss an intelligent solution for implementing custom multithreading by using message-driven beans. This message-driven bean based multithreading framework enables the J2EE container to manage threads and multiple MDBs to execute the business logic in parallel.

Java multithreading makes maximum use of the CPU by keeping the processor's idle time to minimum. To avoid the overhead of creating threads on-the-fly, every J2EE application server container has a default thread pool that contains a set of execute threads. The container can borrow one of the threads from the pool, and assign it a task. Upon completion of the task, the thread goes into a wait state ready to accept another assignment. The J2EE container monitors all execute threads in that pool. Custom threads are different from execute threads. They are created and controlled by the applications rather than the container. This article will introduce a solution implementing custom multithreading in a J2EE container.

Asynchronous Parallel Design Pattern

The analysis model of the custom multithreading framework is based on the concept of asynchronous parallel design pattern. The pattern combines the advantages of delegate, asynchronous, and parallel design patterns. It's a model that consists of an asynchronous interface and a business engine. The business engine is composed of multiple parallel instances of business services, and fulfills the business processes. Figure 1 shows the class diagram representing the structure of the asynchronous parallel pattern.

The client doesn't have to have knowledge of the services that the back-end business engine provides. It simply sends the requests to the delegate, which adds the incoming requests to a mediator repository and returns a result to the client. The client doesn't go into a block state waiting for a response from the back-end business engine. The repository notifies the business engine when new requests are received. The multiple parallel instances of the services in the business engine then pick up the requests from the repository and process them concurrently. Figure 2 shows sequence diagrams that illustrate typical interactions among the components of the asynchronous parallel pattern.

Our example is based on an online brokerage system. We choose to model the process of an investor placing an order that is routed to the market for execution. I simplify the business scenario so we can focus on the custom multithreading framework.

Java Thread-Based Custom Multithreading Framework (CMF)

The components of a Java thread-based CMF include a Thread Pool, Worker Thread, Task Dispatcher, Task, and Task Queue. The class diagram in Figure 3 shows the solution model of a Java thread-based multithreading framework.

The Task interface represents the abstract of the business cases fulfilled in the business process. Business cases are modeled by the Java class that implements the Task interface. For example, the Trade class represents the Stock Trade in a stock trading process. The business logic for processing each business case is implemented in the ‘execute' method of each class.

The TaskFIFOQueue and the TaskDispatcher classes implement the asynchronous interface of the asynchronous parallel pattern. The TaskFIFOQueue class is designed as an intermediary repository that stores unassigned tasks. The TaskDispatcher class works as the delegate of the framework, which receives clients' requests, creates an instance of a Java class implementing Task interface for each incoming request (such as Trade class), adds a new instance to TaskFIFOQueue. The client can continue with other activities without having to wait for its request to be processed. The code snippet in Listing 1 at the end of this article shows how to add or get a task from the TaskFIFOQueue.

The business engine of the asynchronous parallel pattern is implemented by the WorkThread class and the ThreadPool class. The WorkThread class provides the threads that will process the assigned task. Each instance of the WorkThread class is a custom thread, created and controlled by the application. The Thread-Pool class serves as the central control point to manage custom threads. Using an object of the ThreadPool class to store running threads lets us allocate custom threads in a predictable way, reuse an existing thread for multiple tasks, and save time for thread instantiation and initialization. The code in Listing 2 at the end of this article demonstrates how to implement the business engine.

When the TaskDispatcher receives a request from a client, it creates an instance of a particular Task-type class, such as the Trade class, and adds the instance to the TaskFIFOQueue. The TaskFIFOQueue then notifies all waiting threads that a new task is ready to be picked up. The current active WorkerThread gets the task from the TaskFIFOQueue and starts to process the task by running the execute() method of the particular Task-type class. After the WorkThreads finishes the task, it goes into a wait state and is ready to accept the next task. The sequence diagram in Figure 4 illustrates the sample collaborations for the CMF.

Although Java thread-based CMF provides an efficient solution to improve the overall performance of Java applications, it shouldn't be used in applications hosted in the J2EE application server. Java thread-based CMF is discouraged in the J2EE applications for the following reasons.

J2EE Application Server Can't Control Custom Threads
The J2EE application server container is configured to manage all the threads in the Java Virtual Machine. The threads from the CMF won't carry the implicit context that a container normally puts on a thread. The container loses control over the custom threads created explicitly by the CMF because it's not aware of their existence.

Consequently, if a custom thread fails, the container will not be able to detect the failure and so can't recover the thread - either by reclaiming the resources occupied by the particular thread or by restarting it to complete the assigned task. The presence of unmanaged failed threads in the application server can seriously impact the stability, scalability, and performance of the application server.

Thread- Based CMF Affects the Load Balancing in the J2EE Application Cluster
Since a J2EE application server isn't aware of the custom threads in the CMF, it's also not aware of the work being done by the threads, and so won't account for the impact that the additional threads have on the overall workload of the server. This will affect the load balancing of the J2EE application cluster. It will potentially over-assign work to the server, and result in significant throughput or performance problems with the server.

The EJB 2.0 specification integrates EJB with JMS, and defines a new type of Enterprise JavaBean: Message-Driven Bean (MDB). It enables the EJB container to support the asynchronous parallel design pattern. Because the basic theories of the Java thread-based CMF don't negatively impact the application server runtime, we'll use the same analysis model to design the MDB-based CMF. For the purpose of demonstration, the MDB-based framework will be implemented and deployed on WebLogic Server 8.1.

More Stories By Di Li

Di Li, a Sun certified enterprise architect, is an expert in the areas of business process modeling, enterprise architecture design, and software architecting. He has over 10 years of experience in software engineering and technical architecture. Li worked in providing the end-to-end solution of financial services, e-business, and enterprise application integration. You can contact him at victor1998@hotmail.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.