SUMMARY: Added concurrency processing in an application using the J2EE framework is often some strict restrictions, two main reasons: first EJB specification limits new user threads in the EJB container, in addition, SessionBean method must be Synchronous calls. However, in order to ensure the response time, quite a number of applications must implement concurrency process. There are several ways to overcome this limit, wherein the message drive is due to its birthplace, and through JMS. And Message-Driven Beans can be combined with the J2EE application server to become the most prominent solution. This article describes how to use MDBS to implement concurrent processes for J2EE applications. The concurrent program can handle multiple tasks at the same time. Concurrency Improve the data read and write throughput, execution speed, and response speed. In a single processor system, the concurrent program uses the overlapping IO read and write time to utilize the resources of the computer. In multiprocessor system, concurrency programs By maximizing throughput by concurrent executing programs on multiple CPUs. There are several ways to implement concurrency. In Java, you can implement it through multithreading. Compared to independent processes, threads have lower system overhead. Java Support for thread provides an inherent language level, the support of concurrent programs is an indispensable and attractive characteristics of Java. In reality, we will find that concurrent ability is indispensable for many applications. This article is to describe The example is how to search for a minimum price and delivery of a commodity in multiple retail departments. This document describes several different implementations under the J2EE architecture, and how to use MDBS to implement parallel processing under single-user requests. We call this application as Price Buster. In order to prove why Price Buster needs concurrently, let's first discuss what is doing, what functions are needed, and in the J2EE architecture. Our application is accepted by web layer The user-entered goods name or model is used as a search condition, then call the background program to search for the price and supply of multiple supplies, format the results, and finally return to the query. The ideal implementation of this application is Search as much as possible, search as much offer data source. Connect multiple supplies to the background process, accounting for the maximum consumption time. Suppose it takes 15 seconds in a data source querying a cargo, then If the query operation is a series of serials, 10 data sources take at least 150 seconds. For customers, 150 second response time is obviously unacceptable. In the premise of querying multiple data sources In order to ensure the response time, the query operation must be parallel. Not a serial. Now let us discuss, in the use of several different implementation methods under the J2EE architecture. The most typical and general methods are composed of the web module and the EJB module. The web module is implemented by servlets and JSP, responsible for handling customer sessions. And the data shows that the EJB module is responsible for connecting to the supply for the source. The overall architecture is shown in Figure 1. The EJB query module has a priced price from three supply Sources A, B and C, the most important thing is The query operation is serial execution, so the result is displayed to the customer at least 45 seconds. In this implementation, the user's response time relies on the number of supply data sources and the time required for a data source. Although this The implementation provides the correct function, but there is a serious design disadvantage, and the response time increases with the increase in the amount of supply, so the 20 supply mains will take at least 300 seconds, which is obviously unacceptable. In order to correct Implementation and achieve the ideal response time, this application must be redesigned, using additional technology to make the query operation in parallel instead of serial. In other words, we need to implement parallel operations in the above implementation to get a faster response Time. As mentioned above, in the Java program, this can be implemented by multi-thread, for example, for multiple threads allocated a separate task. This technique is focused on IO reading and writing rather than the CPU calculation At the time, it is particularly effective, just as a Price busper program. The EJB component connection database for supply for IO read / write, at least 15 seconds, during this time, the EJB component is only waiting for results, not anything, so this program It is best for the use of multi-threaded implementation. Below is a few ways to support concurrency:
1. Modify the implementation of the web module, use multithreading in the servlet. Each work thread can directly call the EJB component, each working thread is responsible for queries for a supply data source. When there is a request, servlets according to the current data source The quantity, generates several working threads, each thread calls the EJB component for query. At this time, the servlet main thread can wait for the query result or timeout. This method has solved the problem, but it violates the basic design principle of J2EE, Application developers should focus on application logic, and should not be concerned about system-level issues such as multi-threaded and synchronous processing. 2. Search EJB component can generate multiple threads to call Retailer EJB components in parallel. Unfortunately, this The method is completely inexpensive. Because EJB specification is limited to create new user threads in the container. Note that the EJB container itself is implementing concurrency processing, supporting multi-client connection. This restriction is that J2EE technology itself provides an implementation The architecture of a strongly contracted server-side component is to provide concurrency processing and other services. This architecture reduces the difficulty of developers to achieve complex multithreading programs, and the container is more effective in manageing resources by creating threads .3 Using MDBS to implement Retailer EJB components. Search EJB components can simultaneously send several task messages to several retailer components, each received message Retailer component processing task, thereby implementing concurrency processing. Session bean can't achieve this because they must be Synchronous and linearly called. In other words, since MDBS can be called according to the message event asynchronous, we can process the request. We must clear the restriction of the EJB specification. The best implementation is the third: asynchronous Call MDBS. For asynchronous communication between different system components, the message is the most universal and reliable mechanism. By JMS and MDBS technology, message processing has been very close to the J2EE framework. The remaining content of this article will explain how to pass MDBS In EJB support parallel processing. Now let me discuss how to support concurrency processing by MDBS for Price Buster. To use MDBS, you should first use the application server that supports EJB2.0 specification, secondly to support the message software supporting JMS interface. For example, IMB's MQ kit. It is best to choose to be well integrated with the application server, such as WebSphere MQ is a good choice.
In our implementation, as shown in Figure 2, the Retailer component is deployed in MDBS, so it is served by message event instead of the session ejb interface. The following is a complete process. First, the customer provides JSP / servlet The name of the goods or model, servlet calls the Search EJB component, the Search EJB component constructs three JMS messages according to the input, each corresponding to the data source to search, and then put three messages into the request queue. Then Search EJB Components Wait for responding to response messages on the queue (step 2). Request Message Triggered Retailer MDBS, each Retailer MDB responds to a message, while starting the message processing. (Step 3). Search for price and supply information, Retailer MDBS will result Packaging in the JMS message, then place the message into the response queue (step 4), pay attention to all retailer MDBs is the parallel processing message, so they are all returned in approximately 15 seconds. Waiting for the Search EJB components waiting The response queue removes three response messages, parsing the results, and then returns the result to servlet / JSP, display results by the latter. In this method, the shortest response time depends on the response time of a single data source, not the first one. The method also relies on the number of data sources. Therefore, even if the data source is increased to 10, the shortest response time is still nearly 15 seconds. The package and interpretation of the message and the interaction with the message system need a very short time. This The response time compared serial processing 150 seconds, it is a very prominent improvement. When multiple customers initiate query request, there will be multiple SEARCH EJB components, and each served a servlet request. In this In case, there must be a mechanism to map the Group Retailer MDBS and the corresponding calls their EJB components. There are several ways to implement this mapping: 1. Create a temporary response queue for each request. Search EJB component You can create a temporary response queue and package its name with the request parameters in the request message, then put it in the request queue. Retailer MDBS will respond to the temporary response queue of the response message in response to the temporary queue information in the request message. This method simply solves the conflict between different requests, but must consider the cost of creating a temporary queue. If the overhead can be accepted, then this method is desirable, it completely eliminates multiple Search EJB components The possibility of confusing data. 2. Use the response queue pool. This method is the first method, Each temporary response queue is removed from the pool, not every time you create new. In order to manage the queue pool, you must develop an additional management class or an EJB component, which is responsible for assigning the queue in the pool to a Search. EJB component instance, this management class is also responsible for the use of useless messages in the queue object in the pool. After each processing, the Temporary team is returned to the pool. 3. Use JMS Selector mechanism, from the response queue Only the corresponding target response message is taken. JMS allows customers to specify messages that make sense to themselves through the message. Using Selector, the recipient will only receive a message header and other attributes to meet a number of conditions. At this time there is only one response The queue, the Search EJB component creates a key value, then pass the message header to the retailer mdbs, then the Search EJB component creates a Selector object with this key value, all retailabler MDBs will join the key value in the response message header. Search EJB component only A message containing the key value in the message header. The disadvantage of this method is that when the message in the response queue is much, the speed will fall. /* Step 1: CREATE A UNIQUE Key, Use Some Class, Say UniqueKeyCreater. * * / String uniqueKey = uniqueKeyCreater.getKey (); string retailers [] = new string [] {"a", "b", "c"}; / * step 2: put three Messages in the Requestq, One for Each Retailer DEFINE A HEADER CALLED "Key"
and set its value to uniqueKey Note: The retailer MDBs also have to set the same header / value in the response messages ** / QueueSender queueSender = queueSession.createSender (requestQueue); Message message = queueSession.createTextMessage (); message.setStringProperty. ("Key", uniquekey; for (int i = 0; i
