專利名稱：一種Java EE應(yīng)用服務(wù)器并發(fā)處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種Java EE應(yīng)用服務(wù)器并發(fā)處理方法，屬于軟件技術(shù)領(lǐng)域。
技術(shù)背景Java EE (Java Enterprise Environment)是Sun公司提出的基于Java的分布式應(yīng)用的標(biāo) 準(zhǔn)平臺(tái)，它通過提供企業(yè)計(jì)算環(huán)境所必需的各種服務(wù)，使得部署在Java EE平臺(tái)上的基于 構(gòu)件的分布式應(yīng)用可以實(shí)現(xiàn)高可用性、安全性、可擴(kuò)展性和可靠性等特征，是目前應(yīng)用最 為廣泛的面向Web的應(yīng)用系統(tǒng)結(jié)構(gòu)規(guī)范。它為Web應(yīng)用的開發(fā)、部署、運(yùn)行和管理提供 一系列的規(guī)范和標(biāo)準(zhǔn)。Java EE應(yīng)用服務(wù)器通過容器來支持分層體系結(jié)構(gòu)，容器提供了對(duì)Java EE應(yīng)用組件的 運(yùn)行時(shí)支持。圖l顯示了基于JavaEE平臺(tái)的Web應(yīng)用服務(wù)器的基本組成結(jié)構(gòu)，其中Web 容器封裝了 Web服務(wù)器與表示層邏輯的功能，為JavaEE表示層組件(如Servlet)提供了 運(yùn)行時(shí)環(huán)境支持。EJB容器(Enterprise Java Bean Container)封裝了業(yè)務(wù)層功能，為Java EE 業(yè)務(wù)層組件(EJB)提供運(yùn)行時(shí)環(huán)境支持。同時(shí)，JavaEE應(yīng)用服務(wù)器還提供了一系列的底 層服務(wù)(如Java消息服務(wù)、Java連接器體系結(jié)構(gòu)、Java數(shù)據(jù)庫連接服務(wù)等)為Web容器 和EJB容器提供一些底層功能支持，使其能夠訪問企業(yè)數(shù)據(jù)庫與企業(yè)遺留系統(tǒng)，同時(shí)與其 他中間件交互(如消息中間件等)。對(duì)Java EE應(yīng)用服務(wù)器而言，它必須能夠同時(shí)為多個(gè)企業(yè)客戶提供服務(wù)，這種并發(fā)處 理能力由其并發(fā)處理模型通過管理線程資源加以實(shí)現(xiàn)。目前的Java EE應(yīng)用服務(wù)器采用的 并發(fā)處理模型主要是線程池模型，它為每個(gè)客戶請(qǐng)求分配一個(gè)線程資源完成其處理，在輕 負(fù)載的情況下具有較好的性能表現(xiàn)。然而，在Java EE應(yīng)用服務(wù)器中除了線程資源之外還包含大量的共享資源(如數(shù)據(jù)庫 連接、Java消息隊(duì)列等)，它們同樣是完成客戶請(qǐng)求處理所必須的資源。當(dāng)JavaEE應(yīng)用 服務(wù)器面臨重負(fù)載時(shí)，共享資源不足會(huì)造成線程資源阻塞等待，直到獲得相應(yīng)的共享資源 后才能繼續(xù)對(duì)客戶請(qǐng)求的處理，在等待過程中，該線程實(shí)際上處于阻塞狀態(tài)。當(dāng)負(fù)載增大 時(shí)，將造成大量處理線程的阻塞，使得JavaEE應(yīng)用服務(wù)器進(jìn)入飽和狀態(tài)，無法處理后續(xù)的請(qǐng)求，即使該請(qǐng)求并不需要造成線程阻塞的共享資源。可見，采用這種模式在負(fù)載較大 時(shí)對(duì)線程的使用效率較低，從而導(dǎo)致整個(gè)應(yīng)用服務(wù)器的效率較低。通過監(jiān)控共享資源的使用情況指導(dǎo)線程資源的管理能夠有效的減少上述線程阻塞，提 高線程資源的利用率，進(jìn)而提高JavaEE應(yīng)用服務(wù)器的并發(fā)處理能力。發(fā)明內(nèi)容針對(duì)上述現(xiàn)有Java EE應(yīng)用服務(wù)器并發(fā)處理模型存在的問題和不足，本發(fā)明的目的是 提供一種共享資源敏感的Java EE應(yīng)用服務(wù)器并發(fā)處理方法，提高Java EE應(yīng)用服務(wù)器的 并發(fā)處理能力，使其能夠同時(shí)為更多的企業(yè)客戶提供服務(wù)。在本發(fā)明方法中，客戶請(qǐng)求被 包裝為請(qǐng)求事件，通過多個(gè)請(qǐng)求處理單元(Request Processing Unit, RPU)依次處理該請(qǐng) 求事件，各個(gè)請(qǐng)求處理單元完成請(qǐng)求處理的部分功能，并根據(jù)共享資源的使用情況為需要 處理的客戶請(qǐng)求分配線程資源。本發(fā)明方法主要包括以下幾個(gè)要素請(qǐng)求事件、資源上下文與請(qǐng)求處理單元(如圖2 所示)。下面對(duì)這些要素作詳細(xì)介紹(1) 請(qǐng)求事件在本發(fā)明方法中，請(qǐng)求事件是客戶請(qǐng)求的內(nèi)部表示，是請(qǐng)求處理單元的處理對(duì)象。通常情況下，請(qǐng)求事件包含了客戶請(qǐng)求的所有信息。例如，在基于本發(fā)明方法實(shí)現(xiàn)的Web 容器中，請(qǐng)求事件包含了客戶請(qǐng)求的URL、請(qǐng)求參數(shù)值、內(nèi)部的會(huì)話對(duì)象引用等內(nèi)容。(2) 資源上下文資源上下文定義了請(qǐng)求處理單元的共享資源需求，同時(shí)規(guī)定了對(duì)共享資源的一些使用 限制，是請(qǐng)求處理單元分配處理資源的依據(jù)。當(dāng)一個(gè)請(qǐng)求事件到達(dá)請(qǐng)求處理單元后，假如 系統(tǒng)中仍存在空閑的共享資源并且當(dāng)前請(qǐng)求處理單元使用的共享資源沒有超過預(yù)定義的 資源限額，則請(qǐng)求處理單元為該請(qǐng)求事件分配一個(gè)處理資源執(zhí)行請(qǐng)求處理邏輯。對(duì)JavaEE應(yīng)用服務(wù)器而言，應(yīng)用組件由Web應(yīng)用開發(fā)者開發(fā)，Web容器無法事先獲知 其共享資源需求。因此，資源上下文的定義需要Web應(yīng)用開發(fā)者的參與，通過配置文件的 方式與應(yīng)用組件一起部署到Web容器。下面給出了一個(gè)資源上下文的例子，指明了請(qǐng)求處 理單元Search需要類型為AppConnection的資源，最大使用數(shù)量為15。<ResourceContext><RPU〉Search</RPU> <Resources>〈Resource name=，，AppConnection，， max=，，15，，/> </Resources> </ResourceContext>(2)請(qǐng)求處理單元請(qǐng)求處理單元是本發(fā)明方法的核心組件，它將一系列請(qǐng)求處理步驟封裝為請(qǐng)求處理任 務(wù)。同時(shí)，請(qǐng)求處理單元根據(jù)共享資源的使用情況為請(qǐng)求處理任務(wù)分配處理資源，完成請(qǐng) 求處理邏輯。下面首先詳細(xì)介紹了組成請(qǐng)求處理單元的組件，然后給出了請(qǐng)求處理單元的 運(yùn)行原理。*組成結(jié)構(gòu)組成請(qǐng)求處理單元的組件如圖3所示。 一個(gè)請(qǐng)求處理單元由輸入事件隊(duì)列(Input Event Queue)、調(diào)度器(Scheduler)、資源管理器(Resource Manager)、事件處理器(Event Handler)、 任務(wù)管理器(TaskManager)、分發(fā)器(Dispatcher)組成，下面將詳細(xì)介紹每個(gè)組件的具 體功能。(1) 輸入事件隊(duì)列(Input Event Queue)。輸入事件隊(duì)列存儲(chǔ)了所有當(dāng)前請(qǐng)求處理單元需要處理的請(qǐng)求事件。在請(qǐng)求處理單元 內(nèi)部，允許對(duì)請(qǐng)求事件的批量處理，這使得事件處理器能夠在一個(gè)已經(jīng)獲得共享資 源的線程內(nèi)批量處理事件，減少線程的上下文切換。(2) 事件處理器(Event Handler)。 每個(gè)請(qǐng)求處理單元包含一個(gè)事件處理器，它封裝了當(dāng)前請(qǐng)求事件處理流程的一個(gè)或 多個(gè)處理步驟，通常對(duì)應(yīng)一些請(qǐng)求處理組件的處理邏輯，如解析HTTP請(qǐng)求為內(nèi)部 請(qǐng)求對(duì)象。(3) 資源管理器(Resource Manager)。 資源管理器負(fù)責(zé)管理資源上下文并監(jiān)控共享資源的使用情況，作為調(diào)度器線程創(chuàng)建 處理任務(wù)的依據(jù)。(4) 任務(wù)管理器(Task Manager)。任務(wù)管理器負(fù)責(zé)為請(qǐng)求事件創(chuàng)建處理任務(wù)。當(dāng)請(qǐng)求事件的共享資源需求被滿足時(shí)， 調(diào)度器線程創(chuàng)建一個(gè)處理任務(wù)并交給任務(wù)管理器，由任務(wù)管理器為其分配線程資源 以執(zhí)行事件處理器封裝的請(qǐng)求處理邏輯。(5) 分發(fā)器(Dispatcher)。 事件分發(fā)器負(fù)責(zé)將處理后的請(qǐng)求事件根據(jù)其類型分發(fā)到其他請(qǐng)求處理單元的輸入 事件隊(duì)列中，驅(qū)動(dòng)請(qǐng)求處理流程的繼續(xù)執(zhí)行。(6) 調(diào)度器線程(Scheduler)。調(diào)度器線程是請(qǐng)求處理單元的核心，它擁有一個(gè)處理資源。它通過資源管理器監(jiān)控 共享資源的使用情況，并為滿足共享資源需求的請(qǐng)求事件創(chuàng)建處理任務(wù)交給任務(wù)管 理器執(zhí)行。圖4說明了調(diào)度器的狀態(tài)轉(zhuǎn)換圖。1) 開始的時(shí)候調(diào)度器處于空閑狀態(tài)(idle)。2) 當(dāng)請(qǐng)求事件到達(dá)時(shí)，調(diào)度器通過資源管理器查看共享資源的使用情況。如果沒有空閑的貢獻(xiàn)資源，調(diào)度器進(jìn)入資源阻塞狀態(tài)(Resources blocked)。3) 當(dāng)共享資源滿足后資源管理器喚醒調(diào)度器進(jìn)入活動(dòng)狀態(tài)(active)，此時(shí)調(diào)度器為請(qǐng)求事件創(chuàng)建處理任務(wù)并交給任務(wù)管理器，由其分配線程 資源，然后調(diào)度器線程回到空閑狀態(tài)，繼續(xù)等待后續(xù)事件的到來。* 運(yùn)行原理請(qǐng)求事件在請(qǐng)求處理單元中的處理涉及多個(gè)組件，圖5說明了請(qǐng)求事件在請(qǐng)求處理單 元中的處理過程。1) 當(dāng)請(qǐng)求事件進(jìn)入事件隊(duì)列時(shí)，通知調(diào)度器存在請(qǐng)求事件需要處理；2) 調(diào)度器通過資源管理器査看是否存在空閑的共享資源，若不存在則調(diào)度器線程等待;3) 資源管理器通知調(diào)度器已經(jīng)有共享資源釋放，可以處理請(qǐng)求事件；4) 調(diào)度器從事件隊(duì)列取出一批請(qǐng)求事件；5) 調(diào)度器創(chuàng)建處理任務(wù)；6) 調(diào)度器將請(qǐng)求處理任務(wù)交給任務(wù)管理器；7) 任務(wù)管理器為任務(wù)分配線程資源；8) 獲得線程資源的任務(wù)調(diào)用事件處理器的處理邏輯處理事件；9) 分發(fā)器將處理后的請(qǐng)求事件分發(fā)到其他請(qǐng)求處理單元。本發(fā)明提出一種共享資源敏感的JavaEE應(yīng)用服務(wù)器并發(fā)處理方法，和現(xiàn)有技術(shù)相比， 本發(fā)明方法的技術(shù)效果主要為-1. 本發(fā)明方法通過引入請(qǐng)求事件來解耦客戶請(qǐng)求與線程資源的一一對(duì)應(yīng)關(guān)系，使得 每個(gè)請(qǐng)求處理單元能夠根據(jù)共享資源的使用情況為請(qǐng)求事件分配處理資源，超過 處理能力的請(qǐng)求事件在請(qǐng)求事件隊(duì)列中等待，僅阻塞調(diào)度器線程。減少了因共享 資源競(jìng)爭引起的線程資源阻塞，提高了Java EE應(yīng)用服務(wù)器的并發(fā)處理能力。2. 本發(fā)明方法將客戶請(qǐng)求的處理邏輯隔離在不同的請(qǐng)求處理單元中，每個(gè)請(qǐng)求處理 單元僅關(guān)心自己接收和產(chǎn)生的請(qǐng)求事件，這提供了一種靈活的組裝方式，使得調(diào) 試和性能分析更加方便，監(jiān)控代碼能夠方便的放在每個(gè)請(qǐng)求處理單元的入口和出 口來監(jiān)控每個(gè)請(qǐng)求處理單元的性能，有利于性能瓶頸的定位。


圖l是Web應(yīng)用服務(wù)器的基本組成結(jié)構(gòu)圖2是本發(fā)明方法涉及的基本組成組件圖3是請(qǐng)求處理單元組件組成示意4是調(diào)度器線程的狀態(tài)5是請(qǐng)求事件處理的UML順序6是Once Web Container的請(qǐng)求處理流程圖7是Once Web容器的請(qǐng)求處理流程圖8是按照本發(fā)明方法與線程池方法分別設(shè)計(jì)的Web容器性能比較具體實(shí)施方式
以下結(jié)合具體實(shí)施例和附圖對(duì)本發(fā)明作更詳細(xì)的說明。在OnceWebContainer中， 一個(gè)客戶請(qǐng)求的處理過程分為18個(gè)步驟(如圖6所示)，涉及六個(gè)請(qǐng)求處理組件，分別為監(jiān)聽器組件(HTTPListener)、服務(wù)器組件(DefaultServer)、 虛擬主機(jī)組件(DefaultHost)、上下文組件(DefaultContext)、外殼組件(DefaultShell) 以及Servlet組件，其中HTTPListener負(fù)責(zé)監(jiān)聽端口， DefaultServer、 DefaultHost、 DefaultContext、 DefaultShell分別對(duì)應(yīng)Web容器本身、虛擬主機(jī)、Web應(yīng)用以及一個(gè)Servlet 的內(nèi)部表示，Servlet代表應(yīng)用開發(fā)者開發(fā)的實(shí)際應(yīng)用組件實(shí)例。請(qǐng)求處理過程每個(gè)步驟的具體含義如下1) accept,由HTTPListener組件接收客戶端的請(qǐng)求，創(chuàng)建套接字對(duì)象(socket)。2) notifyThread，當(dāng)前的領(lǐng)導(dǎo)者線程通知線程池中的另一個(gè)線程成為領(lǐng)導(dǎo)者，當(dāng)前線程 作為處理線程繼續(xù)處理客戶請(qǐng)求3) handle,調(diào)用DefaultServer進(jìn)行處理4) parseRequest， DefaultServer從socket的輸入流中解析HTTP請(qǐng)求5) parseHeader, DefaultServer從socket中解析HTTP頭信息6) createRequest， DefaultServer創(chuàng)建Web容器的內(nèi)部request對(duì)象7) createResponse, DefaultServer創(chuàng)建Web容器的內(nèi)部response對(duì)象8) service, DefaultServer將請(qǐng)求交給DefaultHost處理9) map, DefaultHost將請(qǐng)求映射到對(duì)應(yīng)的DefaultContext10) service， DefaultHost將請(qǐng)求交給對(duì)應(yīng)的DefaultContext處理11) map, DefaultContext將請(qǐng)求映射到對(duì)應(yīng)的DefaultShell，即Servlet在Web容器內(nèi)部的代表12) service, DefaultContext將請(qǐng)求交給DefaultShell處理13) createFilter，創(chuàng)建對(duì)應(yīng)Servlet的過濾器(Filter)14) doFilter，調(diào)用對(duì)應(yīng)的過濾器邏輯15) service,調(diào)用具體Servlet實(shí)例的service方法，完成業(yè)務(wù)邏輯處理16) return,處理結(jié)果返回給DefaultServer17) prepareHeaders， DefaultServer生成HTTP響應(yīng)頭信息18) sendResponse, DefaultServer將處理結(jié)果返回給客戶端在以上請(qǐng)求處理過程中，步驟l、 2負(fù)責(zé)接收客戶請(qǐng)求，獲得對(duì)應(yīng)的套接字對(duì)象。步驟 4-7負(fù)責(zé)從套接字對(duì)象的輸入流中讀入數(shù)據(jù)，并按照HTTP協(xié)議將其解析為服務(wù)器的內(nèi)部請(qǐng) 求對(duì)象。步驟8-16負(fù)責(zé)將請(qǐng)求對(duì)象映射到對(duì)應(yīng)的Servlet，并由對(duì)應(yīng)的Servlet處理客戶請(qǐng)求。最后，步驟17-18將處理結(jié)果包裝為HTTP響應(yīng)對(duì)象返回給客戶端。假設(shè)當(dāng)前的Web應(yīng)用包含三個(gè)Servlet:管理員請(qǐng)求(Admin Request)、首頁信息(Home) 和搜索請(qǐng)求(Search)，則每個(gè)Servlet的處理流程都對(duì)應(yīng)圖6的請(qǐng)求處理過程，所不同的是 它們具有不同的Servlet實(shí)例。按照本發(fā)明所述方法設(shè)計(jì)Web容器的請(qǐng)求處理流程如下1) 根據(jù)圖6的功能敘述，請(qǐng)求處理流程被劃分為5個(gè)請(qǐng)求處理單元，分別是HTTP 監(jiān)聽器請(qǐng)求處理單元(HTTPListener) 、 HTTP解析器請(qǐng)求處理單元(HTTPParser)、映射器請(qǐng)求處理單元(URLMapper) 、 Servlet方法請(qǐng)求處理 單元(ServletMethod)、響應(yīng)發(fā)送器請(qǐng)求處理單元(ResponseSender)。2) 由于HTTPListener和ResponseSender需要套接字共享資源，因此保持它們作為獨(dú) 立的請(qǐng)求處理單元，而HTTPParser與URLMapper不需要特別的共享資源，二者被合并為 一個(gè)請(qǐng)求處理單元。3) 三個(gè)Servlet中，Home不需要線程資源之外的共享資源。Admin Request和Search 需要數(shù)據(jù)庫連接共享資源以完成對(duì)數(shù)據(jù)庫的査找，同時(shí)AdminRequest還需要安 全數(shù)據(jù)庫連接資源以完成對(duì)管理員身份的認(rèn)證。因此，每個(gè)具體的Servlet都對(duì) 應(yīng)一個(gè)請(qǐng)求處理單元，這樣使得每個(gè)Servlet可以根據(jù)其共享資源需求來為請(qǐng)求 分配線程資源。4) 最終得到的請(qǐng)求處理流程如圖7所示，請(qǐng)求處理流程包含6個(gè)請(qǐng)求處理單元 HTTPListener、 HTTPParser& URLMapper、 Response Sender、 Admin Request、 Home與Search,為了更具體地比較根據(jù)本發(fā)明方法設(shè)計(jì)的Web容器和現(xiàn)有的Web容器在性能上的差 異，本實(shí)施例使用TPC-W基準(zhǔn)測(cè)試程序作為比較標(biāo)準(zhǔn)，該測(cè)試程序由事務(wù)處理性能委員會(huì) (Transaction Processing Performance Council, TPC)在2000年推出，代表一個(gè)典型的電子 商務(wù)應(yīng)用環(huán)境，模擬了一個(gè)有大量并發(fā)的訪問者的網(wǎng)上書店系統(tǒng)。TPC-W模擬了客戶的以下行為完成購物并使用購物車，在存貨表中做搜索，填寫客戶信息，執(zhí)行商店管理的職責(zé)，買購物車?yán)锏纳唐?，査詢最佳售貨員和新商品列表，詢問以前的訂單情況等。同時(shí)，TPC-W還提供了以上客戶行為的三種組成混合類型瀏覽類型(Browsing)、購買類型 (Shopping)以及訂購類型(Ordering)。圖8顯示了基于線程池模型設(shè)計(jì)的Web容器與基 于本發(fā)明方法設(shè)計(jì)的Web容器的性能比較結(jié)果，可以看出，在不同的訪問模式下，本發(fā)明的并發(fā)處理方法都取得了更好的性能。下面給出了有關(guān)請(qǐng)求事件、資源上下文以及請(qǐng)求處理單元接口的部分實(shí)現(xiàn)代碼以更好 地說明本實(shí)施例方法public interface Event { public String getType(); public String getDescription(); public void setDirection(boolean direction); public boolean getDirection(); public Object getProducter(); public Request getRequest(); public Response getResponse(); public void setRequest(Request request); public void setResponse(Response response); public void setSocket(Socket socket); public Socket getSocket(); public InputStream getInputStream(); public OutputStream getOutputStreamO; public void setInputStream(InputStream is); public void setOutputStream(OutputStream os);public interface RPU {public String getName(); public void setName(》public void setEventQueue(Queue<Event> q); public Queue<Event> getEventQueue(); public ResourceContext getResourceContext(); public void setResourceContext(ResourceContext rc); public void setDispatcher(Dispatcher dis); public Dispatcher getDispatcher();public interface ResourceContext { public int getType(); public String getName(); public int getMaxSize(); public int setMaxSize(); public int getAvaiable();具體請(qǐng)求處理單元內(nèi)部的調(diào)度器與處理任務(wù)代碼如下-class Scheduler implements Runnable{public void run() { while(true){Event clientEvent = queue.poll(); if(dientEvent != null)(Task task = new Task(clientEvent); TaskManager.execw^ros^(task);class Task {public Event clientEvent = null; public Task(ClientEvent clientEvent) { this.clientEvent = clientEvent;public void run() { try {forwardRequest(clientEvent); } catch (ServletException e) {e .printStackTrace(); } catch (IOException e) {e.printStackTrace();
權(quán)利要求
1.一種Java EE應(yīng)用服務(wù)器并發(fā)處理方法，其特征在于，所述應(yīng)用服務(wù)器包括一個(gè)或多個(gè)請(qǐng)求處理單元，各個(gè)請(qǐng)求事件依次通過所述請(qǐng)求處理單元中的一個(gè)或多個(gè)進(jìn)行處理；各個(gè)請(qǐng)求處理單元在處理所述請(qǐng)求事件之前查看是否存在處理該請(qǐng)求事件所需的空閑的共享資源，若是，則為當(dāng)前請(qǐng)求處理單元分配線程并處理所述請(qǐng)求事件，若否，則不為當(dāng)前請(qǐng)求處理單元分配線程并等待，直至出現(xiàn)所需的空閑的共享資源。
2. 如權(quán)利要求l所述的方法，其特征在于，在各個(gè)請(qǐng)求處理單元中，僅在處理過程中需 要共享資源的請(qǐng)求處理單元在處理所述請(qǐng)求事件之前査看是否存在處理該請(qǐng)求事件所需的空閑的共享資源。
3. 如權(quán)利要求1所述的方法，其特征在于，所述一個(gè)或多個(gè)請(qǐng)求處理單元實(shí)現(xiàn)互不相同 的處理功能。
4. 如權(quán)利要求1所述的方法，其特征在于，為當(dāng)前請(qǐng)求處理單元分配線程前還檢驗(yàn)當(dāng)前 請(qǐng)求處理單元所需的共享資源是否超過預(yù)定義的資源限額，若否，則為其分配線程。
5. 如權(quán)利要求1所述的方法，其特征在于，所述請(qǐng)求處理單元在同一線程內(nèi)批量處理該 請(qǐng)求處理單元內(nèi)待處理的請(qǐng)求事件。
6. 如權(quán)利要求1到5任意一項(xiàng)所述的方法，其特征在于，所述請(qǐng)求處理單元由輸入事件 隊(duì)列、調(diào)度器、資源管理器、事件處理器、任務(wù)管理器和分發(fā)器組成；所述輸入事件隊(duì)列存儲(chǔ)所有當(dāng)前請(qǐng)求處理單元需要處理的請(qǐng)求事件；所述調(diào)度器通過資源管理器監(jiān)控共享資源的使用情況，并為滿足共享資源需求的請(qǐng)求 事件創(chuàng)建處理任務(wù)交給任務(wù)管理器；所述資源管理器管理資源上下文并監(jiān)控共享資源的使用情況，作為調(diào)度器線程創(chuàng)建處 理任務(wù)的依據(jù)；所述事件處理器對(duì)應(yīng)請(qǐng)求處理組件的處理邏輯，完成其處理功能； 所述任務(wù)管理器負(fù)責(zé)為請(qǐng)求事件創(chuàng)建處理任務(wù)；所述分發(fā)器負(fù)責(zé)將處理后的請(qǐng)求事件根據(jù)其類型分發(fā)到其他請(qǐng)求處理單元的輸入事 件隊(duì)列中，驅(qū)動(dòng)請(qǐng)求處理流程的繼續(xù)執(zhí)行。
7. 如權(quán)利要求6所述的方法，其特征在于，所述請(qǐng)求處理單元的處理過程包括下列步驟:a) 請(qǐng)求事件進(jìn)入所述事件隊(duì)列，通知所述調(diào)度器存在請(qǐng)求事件需要處理；b) 所述調(diào)度器通過所述資源管理器查看是否存在空閑的共享資源，若不存在則調(diào)度 器線程等待；c) 所述資源管理器通知所述調(diào)度器己經(jīng)有共享資源釋放，可以處理請(qǐng)求事件；d) 所述調(diào)度器從事件隊(duì)列中取出一批請(qǐng)求事件；e) 所述調(diào)度器創(chuàng)建處理任務(wù)；f) 所述調(diào)度器將請(qǐng)求處理任務(wù)交給所述任務(wù)管理器；g) 所述任務(wù)管理器為任務(wù)分配線程資源；h) 獲得線程資源的任務(wù)調(diào)用所述事件處理器的處理邏輯處理事件;i) 所述分發(fā)器將處理后的請(qǐng)求事件分發(fā)到其他請(qǐng)求處理單元。
全文摘要
本發(fā)明公開了一種Java EE應(yīng)用服務(wù)器并發(fā)處理方法，屬于軟件技術(shù)領(lǐng)域。本發(fā)明所述應(yīng)用服務(wù)器包括一個(gè)或多個(gè)請(qǐng)求處理單元，各個(gè)請(qǐng)求事件依次通過所述請(qǐng)求處理單元中的一個(gè)或多個(gè)進(jìn)行處理；各個(gè)請(qǐng)求處理單元在處理所述請(qǐng)求事件之前查看是否存在處理該請(qǐng)求事件所需的空閑的共享資源，若是，則為當(dāng)前請(qǐng)求處理單元分配線程并處理所述請(qǐng)求事件，若否，則不為當(dāng)前請(qǐng)求處理單元分配線程并等待，直至出現(xiàn)所需的空閑的共享資源。和現(xiàn)有技術(shù)相比，本發(fā)明方法減少了因共享資源競(jìng)爭引起的線程資源阻塞，提高了Java EE應(yīng)用服務(wù)器的并發(fā)處理能力，同時(shí)使得調(diào)試和性能分析更加方便，有利于性能瓶頸的定位。
文檔編號(hào)G06F9/50GK101334742SQ200810117820
公開日2008年12月31日 申請(qǐng)日期2008年8月5日 優(yōu)先權(quán)日2008年8月5日
發(fā)明者張文博, 洋 李, 華 鐘, 峻 魏, 濤 黃 申請(qǐng)人:中國科學(xué)院軟件研究所