Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
A concurrent program is one that can execute multiple tasks simultaneously. Concurrency improves a program's throughput, execution speed, and responsiveness. On a single processor system, concurrent programs efficiently use computer resources by overlapping slow I/O (input/output) operations with computational tasks; on a multiprocessor system, concurrency helps maximize throughput by executing tasks in parallel on different CPUs.
Concurrency can be achieved in multiple ways. In Java, concurrency is easily achieved by multithreading. Threads have a lower overhead as compared to independent processes, and Java provides built-in support for threads. Thus, concurrent programming is an integral and desirable feature for Java programs.
Many real-world applications find parallel processing either necessary or highly desirable. One such example is an application that displays the best price and availability of an item by searching multiple retailers. This article discusses various implementations of this example application, called Price Buster, in a J2EE (Java 2 Platform, Enterprise Edition) framework and describes how message-driven beans (MDBs) can effectively achieve parallel processing of a single user request.
To justify the need of concurrent processing for the Price Buster application, let us discuss what this application does, the desirable features, and the best way to implement it in the J2EE framework. Our sample application takes an item name or model number as user input over the Web, invokes a backend process that searches the item's price and availability from multiple retailers, formats the data, and presents it to the user.
This application's ideal implementation is one that can search many retailers in the shortest possible time. Out of the total time required to process one user request, the backend process that connects to multiple retailer systems will spend the maximum time to gather pricing information. Let's assume it takes a minimum of 15 seconds to search an item's details from a retailer. Hence, searching 10 retailers requires a minimum of 150 seconds, assuming the retailers are searched serially, one after the other. From the user's viewpoint, a response time of 150 seconds is completely unacceptable. To ensure an acceptable user response time while searching numerous retailers, the implementing technology must search in parallel rather than serially.
Now let us discuss the different implementation options available if the Price Buster application needs to be implemented in the J2EE framework. The typical and most common implementation in a J2EE environment would consist of a Web module (servlets and JavaServer Pages, or JSP) that handles the session and presentation, and a J2EE module with EJB (Enterprise JavaBeans) components containing the business logic to connect and search the retailers' legacy systems, as illustrated in Figure 1. The user invokes the JSP/servlet over the Web, which, in turn, invokes a method on the search EJB component. The search EJB component gets the item's price and availability from three retailers A, B, and C by invoking retailer EJB components, one after the other. The important point to note here is that the retailers are searched sequentially. Because of the serial invocation, a minimum of 45 seconds will pass before the results display to the user.
|Forum migration complete By Athen|
|Forum migration update By Athen|
|Threads in the web tier By kevg|
|is concurrency really a issue with Session Beans?? By AnoopB|
|Asynchronous Request - With no client block. By Anonymous|
|why 3 separate messages? By gopnik|
|blocking call By seang|
|why not use JavaSpaces? By Anonymous|
|Transactions? By Griffin|