有狀態程序實體的工作負荷管理的製作方法
2023-06-05 05:49:46 1
專利名稱：有狀態程序實體的工作負荷管理的製作方法
技術領域：
本發明涉及維護易失性存儲器中的狀態的程序實體的工作負荷管理，具體來說，涉及諸如Enterprise JavaBeansTM體系結構的有狀態會話bean之類的對象的重新定位。
背景技術：
在客戶端-伺服器企業系統中進行工作負荷管理現在是普遍現象。在工作負荷管理系統中，設置一組伺服器進程(工作組)，以便工作組中的每一個伺服器進程都具有類似的能力。這使得工作組中的每個伺服器進程都代表客戶端處理給定的請求(或消息)。當客戶端向工作組發送請求時，工作負荷管理單元決定將請求分配給工作組中的哪一個伺服器進程。這通常基於用戶定義的策略，這種策略可以是，最不忙或循環復用。這樣就有希望確保，有效地使用伺服器進程資源，客戶端由於單伺服器進程同時為許多客戶端運行請求所引起的瓶頸而造成的響應速度較慢的可能性較小。
圖1顯示了一個典型的工作負荷管理系統。該系統包括許多客戶端通過網絡(11)與工作負荷管理單元(12)進行通信的許多客戶端(10)。工作負荷管理單元(12)通過網絡(11)向包括兩個伺服器進程的工作組分配工作，每一伺服器進程都在伺服器(13和14)中運行。當客戶端發出請求時，工作負荷管理單元接收該請求，並選擇伺服器進程，以便將請求分配給該伺服器進程。工作負荷管理單元可以是組成工作組的一個或多個伺服器進程的一部分。
在理想的情況下，在這樣的系統中，工作負荷管理單元基於所選擇的策略為接收到的每一個客戶端請求隨意選擇伺服器進程，因為，這樣能夠更好地分配工作。然而，這並不總是可以實現的。例如，在一個請求中，客戶端可以在一個給定伺服器進程中創建一個對象實例，而該伺服器進程包含客戶端在隨後的請求中需要訪問的數據。為使客戶端正確地工作，工作負荷分配單元必須確保客戶端可以訪問正確的對象實例。這可以這樣來實現，通過在客戶端的壽命內維護客戶端-伺服器關係的某些元素，以確保，當客戶端以後需要訪問在其中創建了對象實例的伺服器進程時，客戶端能夠返回到該伺服器進程，或者通過使對象實例能在響應不同請求時在各個伺服器進程之間移動，而不會改變狀態。如果唯一可用的選項是客戶端-伺服器關係，那麼，工作負荷分配將受到不利的影響，因為唯一可以做到的是對客戶端請求的子集進行工作負荷管理，如果說預測當客戶端-伺服器關係被固定時客戶端施加於伺服器進程的負荷不是不可能的話，也是比較困難的。
因此，優選情況下，最好能使對象在請求之間移動伺服器進程。對於維護資料庫(或文件)中的狀態數據的對象是相當簡單的，因為對象實例可以從工作組中的任何伺服器進程訪問資料庫或文件。結果，對象實例可以移到任何伺服器進程中，雖然如果它參與事務，則在事務完成之前對象無法移動，因為在事務期間進行的資料庫更改只有在事務提交之後才被加固到資料庫。然而，如果對象實例保留易失性存儲器中的狀態數據，則它無法輕易地在伺服器進程之間移動。這是因為，易失性存儲器通常只能從分配它的伺服器進程進行訪問。結果，如果客戶端使用這種類型的對象，則實施客戶端-伺服器關係，工作負荷管理將受到所討論的限制。
這可以通過查看在這樣的工作負荷管理客戶端-伺服器企業系統中使用的特定的編程模式來進行說明。一個好的示例是行業標準Enterprise JavaBeansTM(EJBTM)編程模式。此模式在SunMicrosystems，Inc.推出的Enterprise JavaBeans v1.1規範中進行了全面的定義，該規範在這裡進行了引用。為清楚起見，現在描述此規範的某些特點。
Enterprise JavaBeans v1.1規範基於EJB對象的功能描述了在伺服器進程中運行的EJB(對象)的分類。兩個類別是會話bean和實體bean。會話bean通常代表客戶端執行；可以訪問資料庫但不代表資料庫；壽命短；不可恢復。實體bean通常對多個客戶端可訪問；代表資料庫；壽命長；可恢復。會話bean進一步可以分類為無狀態的或有狀態。無狀態會話bean實例不包含會話狀態，以便客戶端可以使用會話bean的任何實例。然而，有狀態會話bean實例卻包含客戶端可能需要重複訪問的會話狀態。結果，客戶端必須始終訪問具有所需的狀態的有狀態會話bean的實例。由於此狀態至少部分地保留在易失性存儲器中，這通常需要客戶端始終訪問有狀態會話bean的同一實例。
EJB容器為EJB在伺服器進程中提供了一個執行環境。Enterprise JavaBeans v1.1規範指定了客戶端和容器以及EJB和其容器之間的合同。容器和客戶端之間的合同的一部分是為EJB提供一個宿主，客戶端可以進入到其中，以創建新的EJB實例並定位現有的EJB實例。EJB和其容器之間的合同的一部分指定了EJB必須實現的方法，以便使容器能夠給bean實例提供對容器服務的訪問，並向bean實例發出通知。這些方法隨著bean的類型而變化。例如，有狀態會話bean必須實現的兩個方法是ejbActivate和ejbPassivate。當容器即將通過序列化bean實例並將它寫入到磁碟中來鈍化bean實例時，在bean實例上調用ejbPassivate。這可以由於種種原因來進行，如，bean在其中被實例化的伺服器進程的內存容量低和/或bean實例在指定的時間段內沒有被訪問。然而，由於會話bean可以被事務識別，當bean實例參與事務時，容器無法鈍化bean實例。在ejbPassivate方法中，bean實例必須確保，至少部分地保留在內存中的其會話狀態，可以不被鈍化，因此，例如，它必須關閉它打開的任何JDBCTM連接。一旦bean實例被鈍化，可以通過從磁碟中讀取其序列化的形式，解除其序列化，然後調用其ejbActivate方法來重新活化。結果，在ejbActivate方法中，bean實例可以重新打開任何在鈍化期間被關閉的JDBC連接。
圖2是所描述的EJB編程模式的略圖。它顯示了提供EJB容器(201)的EJB伺服器進程(20)。對於每一個實現的EJB，提供了EJB宿主(202)，該宿主可以被客戶端(10)用來創建該EJB(203)的實例。EJB伺服器進程(20)可以為許多EJB實現提供宿主。EJB實例(203)在EJB容器(201)提供的環境中執行，一旦創建實例，客戶端(10)就可以向它發送請求。隨時都可能有相同或不同的客戶端創建的EJB的許多實例(204，205)。
圖3a和3b是有狀態會話bean鈍化和重新活化的略圖。圖3a顯示了在易失性存儲器中維護bean的計數器的名為BeanCounter的有狀態會話bean的實例。在鈍化期間，Deancounter實例(302)從EJBServer(20)中的易失性存儲器中刪除，並以其序列化的形式(304)寫入到磁碟上的bean存儲區中(303)。序列化的形式包含BeanCounter實例(302)的會話狀態(beans＝5)。BeanCounter實例(302)是以虛線繪製的，以表示，它已經從易失性存儲器中刪除，並且在結束鈍化時，它只以其序列化形式(304)存在於磁碟之中。圖3b顯示了重新活化，這是鈍化的相反過程。從磁碟中讀取bean實例(304)的序列化形式，並作為Beancounter實例(302)重新活化。在重新活化之後，實例存在於易失性存儲器中，並包含在鈍化之前它包含的會話狀態(beans＝5)。在此過程之後，bean實例(304)的序列化形式可以也可以不必存在於磁碟中。
現在可以看出，在使用EJB編程模式的工作負荷管理系統中，工作負荷管理單元必須對客戶端以前訪問的EJB的類型敏感。例如，如果客戶端只訪問無狀態會話bean實例，那麼，來自客戶端的任何請求都可以由工作負荷管理單元基於所選擇的分配策略，分配給工作組中的任何伺服器進程。這是因為，這些bean不包含會話狀態。如果客戶端訪問實體bean實例，則它們還可以移動伺服器進程，但只能在事務之間進行，因為實體bean在資料庫保持狀態並且是事務性的。然而，如果客戶端創建並訪問有狀態會話bean實例，由於實例可以在易失性存儲器中包含會話狀態，客戶端在客戶端的壽命內將保持與在其中創建bean的伺服器進程的關係，以便來自客戶端的所有隨後的發往bean實例的請求都被給予相同的伺服器進程。如果bean在請求之間被鈍化，則當接收到鈍化之後的第一個請求時，bean在伺服器進程中被重新活化。
提供使用EJB編程模式的工作負荷管理系統的產品的一個示例是BEA Systems，Inc.的BEA Weblogic ServerTM6.0產品。該產品將工作組叫做伺服器群集。以兩種形式提供工作負荷管理。EJB宿主對象可以具有識別群集的宿主存根，該存根了解群集中的所有伺服器進程上的所有EJBHome對象。此存根為客戶端請求提供工作負荷平衡，以創建和查找EJB實例。EJB可以具有識別副本的EJBObject存根，該存根了解駐留在群集中的伺服器進程的EJB的所有副本。EJBObject存根為EJB方法調用提供負載平衡和故障轉移服務。無狀態會話bean可以是識別副本的，並具有識別群集的宿主，以便創建和訪問無狀態會話的所有請求的工作負荷都可以得到管理。然而，有狀態會話bean只能具有識別群集的宿主，因此只有創建有狀態會話bean的調用的工作負荷才可以得到管理。到有狀態會話bean實例的所有請求一般來說被給予相同的伺服器進程。使用有狀態會話bean實例的內存中的複製提供了這一情況的例外。對於內存中的複製，有狀態會話bean被給予削減識別副本的對象存根，該存根bean實例維護了在上面運行的主伺服器進程實例，以及一個輔助伺服器進程實例，以便用於複製bean的狀態。現在如果客戶端在事務的範圍內修改bean實例的狀態，當事務被提交時，bean實例的狀態在輔助伺服器進程中的易失性存儲器中複製。萬一bean實例的主伺服器進程發生故障，則客戶端請求被重新路由到輔助伺服器進程，該輔助伺服器進程變成主伺服器進程，並從群集中分配一個新的輔助伺服器進程。在此情況下，客戶端自動獲得對bean的最後一個提交的狀態的訪問。這為有狀態會話bean提供了故障轉移支持而不是工作負荷管理，並需要伺服器協調bean實例的內存中的副本的刪除。還可以看出，如果有狀態會話EJB實例在未完成的事務中被修改，當主伺服器發生故障時，到EJB實例的下一個請求將不會失敗，但會丟失未提交的更改。結果，客戶端永遠不會知道有狀態會話bean實例是否丟失未提交的更新。
發明內容
因此，需要提供用於包含易失性存儲器中保留的狀態數據的程序實體的工作負荷管理。
根據第一個方面，本發明提供了一種用於在數據處理系統上運行的數據處理方法，所說的數據處理系統具有非易失性存儲器存儲設備，該方法包括下列步驟作為伺服器進程的一部分，通過將程序實體的實例寫入到所說的存儲設備上的程序實體存儲區，並從所說的伺服器進程中將其刪除，來鈍化所說的程序實體的實例；作為伺服器進程的一部分，通過從所說的程序實體存儲區讀取所說的程序實體的實例，並在所說的伺服器進程中重新創建它，來重新活化所說的程序實體的實例；其中，鈍化以及隨後重新活化所說的特定程序實體實例的伺服器進程是不同的，其特徵還在於根據工作負荷分配算法選擇在其中重新活化特定程序實體實例的伺服器進程。
根據第二個方面，本發明提供了一種用於執行上文描述的數據處理方法的電腦程式產品。
根據第三個方面，本發明提供了一種數據處理系統，包括至少一個伺服器；許多能夠在所說的至少一個伺服器上運行的伺服器進程，其中每個伺服器進程都支持程序實體；以及每一個伺服器進程都可以訪問到的非易失性存儲器存儲設備；其中每一個伺服器進程都包括用於通過將所說的程序實體的實例寫入到所說的存儲設備上的程序實體存儲區來鈍化所說的程序實體的實例的裝置；以及用於通過從所說的程序實體存儲區讀取所說的程序實體的實例，並使用它來重新創建所說的程序實體實例，來重新活化所說的程序實體的實例的裝置；其中，重新活化的裝置可以重新活化被不同的伺服器進程的鈍化裝置鈍化的程序實體實例，其特徵還在於，用於根據工作負荷分配算法選擇在其中重新活化所說的特定程序實體實例的伺服器進程的裝置。
如此，本發明能使維護易失性存儲器中的狀態數據的程序實體的實例通過在一個伺服器進程中鈍化並在第二個伺服器進程中重新活化來在伺服器進程之間移動。結果，如果實體在請求之間移動伺服器進程，則訪問程序實體實例的請求可以受到工作負荷管理，由工作負荷管理單元選擇它所移向的伺服器進程。由於鈍化步驟將程序實體實例的序列化形式寫入到磁碟，而重新活化步驟在重新創建程序實體實例時解除序列化形式的序列化，因此，程序實體的狀態數據得到維護。
優選情況下，為其提供工作負荷管理支持的程序實體是Enterprise JavaBean規範的有狀態會話bean的實例。結果，如Enterprise JavaBeans所描述的，鈍化和重新活化涉及ejbPassivate和ejbActivate。或者，程序實體也可以是Java bean或C++對象的實例。
優選情況下，本發明進一步為涉及程序實體實例的工作單元提供了工作負荷管理。工作單元將諸如請求之類的一個或多個事件分隔為單個的單元。優選情況下，工作單元是CORBA對象事項服務事務。或者，工作單元可以是，不同類型的事務，會話、業務方法、IBM CICS工作單元或客戶端請求。另一種類型的事務的示例是Java事務API事務。這是通過在所選的工作單元完成時，而不是在此期間鈍化程序實體來實現的。
優選情況下，本發明進一步向客戶端提供保證，在諸如事務之類的一個工作單元下訪問的程序實體實例，在工作單元完成之前，無法超出工作單元的範圍之外重新訪問。結果，如果工作單元由於在其中執行的伺服器進程發生故障而不能完成，則程序實體實例將停止存在。這可以通過確保程序實體實例在重新活化期間從程序實體存儲區刪除來實現。
優選情況下，提供了包含可用於定位程序實體實例的信息的路由表。程序實體實例在為程序實體提供支持的許多伺服器進程中的任何一個伺服器進程中是活化的，或者，在不同的時間在bean存儲區中是鈍化的。然後可以在收到訪問程序實體實例的請求之時使用路由表，將請求定向到程序實體當前在其中是活化的的伺服器進程中，或如果程序實體當前是鈍化的，則定向到任何伺服器。程序實體存在於程序實體存儲區中可以由路由表中沒有與程序實體相關的項來表示。
優選情況下，減少對路由表的訪問。如果與程序實體實例關聯並用於將程序實體標識為請求的目標的鍵包括一個標誌，表示程序實體實例的位置信息在路由表中存在，就可以實現這一點。然後，在收到入站請求之時，可以使用這一標誌決定是否在路由表中查找bean實例的位置。例如，與有狀態會話bean實例關聯的鍵可以包括表示bean實例參與到不完整的bean管理事務中的標誌。這可能是路由表將包括bean實例的位置信息的唯一情況，因此，當接收到一個bean實例請求時，只需要搜索路由表，查看其中bean實例是否設置了bean管理的標誌。
下面將參考下面的附圖，對本發明的優選實施例進行描述圖1是優選情況下應用了本發明的優選實施例的數據處理環境的方框圖；圖2是與本發明有關並在優選情況下應用了本發明的Enterprise JavaBeans功能的略圖；圖3a和3b分別是根據Enterprise JavaBean規範的有狀態會話bean鈍化和重新活化的略圖；圖4a和4b是本發明的優選實施例中的主要部件之間涉及的流程的順序圖；圖5是本發明的優選實施例的略圖；圖6是根據本發明的優選實施例的在磁碟上保存的能進行有狀態會話bean的工作負荷管理的信息類型的說明圖；以及圖7是根據本發明的優選實施例的當向伺服器分配入站請求時工作負荷管理單元所遵循的邏輯的流程圖。
具體實施例方式
圖1顯示了優選情況下應用了本發明的優選實施例的數據處理環境。在該圖中，客戶端數據處理設備(10)通過網絡(11)連接到工作負荷管理單元設備(12)，網絡可以是網際網路。客戶端向工作負荷管理單元設備(12)發送請求(或消息)，工作負荷管理單元設備(12)通過網絡(11)向數據處理伺服器Server1(13)和Server2(14)分配請求，其中每一個伺服器都包括處理這些請求的伺服器進程。Server2(13)和Server2(14)的伺服器進程能夠處理等效的請求並構成一個工作組。雖然在此實施例中工作組包括兩個伺服器進程，每一個伺服器進程都來自不同的數據處理伺服器，但是，在其他實施例中，數據處理伺服器可以包括一個或多個伺服器進程，工作組可以包括來自一個或多個數據處理伺服器的兩個或更多伺服器進程。
Server1(13)具有用於控制伺服器的操作的處理器(131)，用於臨時存儲諸如有狀態會話bean的存儲器中的實例之類的數據的易失性存儲器元件(132)，用於存儲諸如鈍化有狀態會話bean的序列化形式之類的數據的非易失性存儲器(133)，以及用於與網絡(11)進行連接的網絡連接器(134)。雖然未顯示，但是，客戶端(10)、工作負荷管理單元(12)和Server2(14)由與Server1的相同組件(131、132、133、134)構成，至少一個伺服器的非易失性存儲器(133)必須能夠被工作組中的其他伺服器訪問。值得注意的是，在優選實施例中，雖然工作組由兩臺伺服器組成，但是，在其他實施例中，工作組可以由兩臺以上的伺服器構成。也是在優選實施例中，與構成工作組的伺服器(13和14)分開顯示了客戶端(10)和工作負荷管理單元(12)，但是，在其他實施例中，這些設備中的一個或多個也可以是工作組中的伺服器。此外，在優選實施例中，Server1(13)包括單個組件(131、132、133、134)，但是，在其他實施例中，可以有這些元件中的一個或多個，相反，工作組中的一個或多個伺服器也可以共享這些組件。
在優選實施例中工作組提供了Enterprise JavaBeans編程模式的支持，同樣也提供了有狀態會話bean的支持；提供的事務服務是與CORBA兼容的對象事務服務(OTS)；工作負荷管理單元提供了事務關係的支持，以便在一個給定事務下的所有請求都由工作組中的相同的伺服器進程進行處理。
圖4a和4b顯示了，根據本發明的優選實施例，可以從在兩個單獨的客戶端啟動的事務的範圍內創建並訪問一個給定有狀態會話的bean的客戶端產生的流程的序列。然而，請注意，所顯示的流程只是將實際發生的與優選實施例有關的流程的子集。在此示例中，給定有狀態會話bean是BeanCounter bean，該bean可以由客戶端用來在客戶端的壽命內統計bean。雖然這好像是一個有點過分簡單的有狀態會話bean，但是，bean統計確實具有保留在內存中的會話狀態，完全可以適合用於此描述。然而，值得注意的是，本發明同樣可以應用於在實踐中可能比較複雜並也可以訪問資料庫中的數據的任何給定的有狀態會話bean實例。
圖4a顯示了客戶端的第一個事務的處理過程。客戶端(401)發出開始事務請求(403)，工作負荷管理單元(未顯示)將該請求分配給EJBServer1(402)中的事務服務，並建立事務與此伺服器進程的關係。在事務被啟動之後，客戶端定位BeanCounter宿主，並向它發送一個創建請求(404)。工作負荷管理單元向EJBServer1(402)分配此請求，以維護事務-伺服器關係，BeanCounter宿主用bean＝0的初始狀態實例化新(405)BeanCounter實例。在從創建請求返回之前，知道在事務下創建BeanCounter實例的容器，發出register_synchronization請求(406)以向事務服務註冊同步對象所擁有的容器。這將確保，在事務完成處理期間用after_completion調用容器。當客戶端發出將bean狀態更新到beans＝1的增量請求(407)時，客戶端訪問BeanCounter實例。工作負荷管理單元還將此請求分配到EJBServer1(402)以維護事務-伺服器關係。當客戶端即將完成事務時，它向事務服務發出提交請求(408)，該請求作為容器註冊的同步對象上的提交處理調用after_completion(409)的一部分。然後，此對象調用BeanCounter實例上的ejbPassivate(410)，因為，根據本發明，在事務的範圍內訪問的有狀態會話bean實例在該事務完成時被鈍化。在此示例中，BeanCounter實例在ejbFassivate中無事可做，因為它沒有打開的JDBC連接，其狀態是可序列化的。在調用ejbPassivate之後，容器序列化BeanCounter實例，將它從易失性存儲器中刪除，並將它寫入(411)到bean存儲區。bean存儲區不可恢復，保留在非易失性存儲器中，在優選實施例中，非易失性存儲器是一個硬碟。在事務完成時，工作負荷管理單元取消事務與EJBServer1(402)的關係。
請注意，在圖4a中，提交了事務，雖然所描述的處理與提交請求(408)是一個回滾請求的情況相同。此外，雖然優選實施例使用了同步對象和after_completion方法以幫助在事務完成時鈍化bean實例，但是，其他實施例也可以採用不同的方法。
處理過程在圖4b中繼續，該圖顯示了客戶端的第二個事務。客戶端(401)發出開始事務請求(413)，工作負荷管理單元(未顯示)將此請求分配給EJBServer2(412)中的事務服務，並建立事務與此伺服器進程的關係。然後，客戶端向BeanCounter實例發出增量請求(414)。此請求基於建立的事務-伺服器關係分配給EJBServer2(412)。容器認識到，bean實例不在易失性存儲器中，從bean存儲區讀取並將它刪除(415)。然後，將bean實例解除序列化到易失性存儲器，並在其上調用ejbActivate方法(416)。在本示例中，BeanCounter實例在ejbActivate中無事可做，無法恢復其狀態。然後，將增量請求(414)傳遞到BeanCounter實例，該請求將其狀態更新到beans＝2。在增量方法返回之前，容器注意到，這是BeanCounter實例在此事務中的第一次使用，因此，它發出register_synchronization請求(417)以向事務服務註冊同步對象所擁有的容器。這將確保，在事務完成處理期間用after_completion調用容器。當客戶端即將完成事務時，它向發出提交請求(418)，處理過程以與為圖4a所描述的從提交請求(408)開始的同樣的方式繼續。
如此，有狀態會話bean實例在事務之間移動伺服器進程，結果，每一個事務的工作負荷都得到管理。在沒有本發明的情況下，創建(404)有狀態會話bean實例將建立客戶端-伺服器關係，該關係將導致所有客戶端的事務在相同伺服器進程中運行。
值得注意的是，雖然上面的示例考慮了客戶端啟動的事務，但是，本發明還適用於容器或bean啟動的事務。對於容器和bean啟動的事務，所涉及的流程將類似於所描述的那些。在這樣的情況下，優選實施例中的區別是，圖4a和4b中的客戶端(10)調用的方法將由不同的實體發出。例如，不同的EJB的容器或另一個EJB實例，可以發出開始(403、413)和提交(408、418)請求，另一個EJB實例或客戶端，可以發出創建(404)和增量方法(407、414)。
此外，在單個客戶端請求內啟動和完成容器管理的事務。結果，作為容器管理事務的一部分被訪問的有狀態會話bean實例，在每個客戶端請求完成時被鈍化。這就可以對使用容器管理事務的所有客戶端請求進行工作負荷管理。然後可以看出，在沒有事務的情況下，容器還可以在非事務請求完成時鈍化有狀態會話bean實例，從而即使有狀態會話bean實例被訪問，也可以對所有請求進行工作負荷管理。
圖5是根據本發明的優選實施例的圖4a和4b所示的事務的略圖。客戶端(401)運行兩個事務T1和T2，並在每一個事務的過程中，BeanCounter實例(503)被訪問。T1-a(501)代表客戶端(401)作為事務T1的一部分發出的請求。工作負荷管理單元(12)將所有這些請求路由到EJBServer1(402)，這些請求由T1-b(502)代表。在事務完成時，BeanCounter實例(503)的序列化表示寫入(504)到bean存儲區(509)並從EJBServer1(402)中的存儲器刪除。T2-a(506)代表客戶端(401)作為事務T2的一部分發出的請求。工作負荷管理單元(12)將所有這些請求路由到EJBServer2(412)，這些請求由T2-b(507)代表。T2首次訪問BeanCounter實例時，通過從bean存儲區(509)讀取並從中刪除(508)，並在EJBServer2中的存儲器中重新實例化，它在EJBServer2(402)中重新活化。結果，即使T1在不同的伺服器中運行，T2也可以訪問T1留下的BeanCounter實例的狀態。然後，T2將bean實例的狀態增加到beans＝2。
圖6是根據本發明的優選實施例的在非易失性存儲器上保存的能進行有狀態會話bean的工作負荷管理的信息類型的說明圖。顯示了根據本發明可以實現的狀態的序列的兩個文件的內容，可恢復的路由文件，以及不可恢復的bean存儲區。請注意，所顯示的內容是保留的信息的細節，而不是文件的實際內容，因為保留信息的方式有許多種。此外，狀態也不是詳盡的，只是用來說明概念。
在圖6所示的第一狀態中，在Server1中有一個ID為T1的活動事務，在bean存儲區有一個鍵為B1的鈍化會話bean實例。路由表包含(601)事務id(T1)和在其中啟動事務(server1)的伺服器進程的表示。此信息用於維護事務-伺服器關係，以便作為事務T1的一部分的所有請求都被路由到server1。bean存儲區包含(602)會話bean鍵(B1)和其會話狀態(beans＝1)。在此狀態下，任何從工作組中的任何伺服器進程訪問bean實例的嘗試都將會成功。
圖6中的第二個狀態是在bean實例B1在事務T1的範圍內重新活化之後第一個狀態的繼續。路由表內容(603)未變化，但bean實例的記錄已經從bean存儲區刪除，該bean存儲區現在沒有bean實例B1的記錄(604)。這是因為，bean實例B1現在在server1中的易失性存儲器中，因此，從server1的任何訪問它的嘗試都將會成功，但從工作組中的任何其他伺服器進程訪問都將會失敗。
圖6中的第三個狀態是在事務T1被提交之後第二個狀態的繼續。路由表現在沒有已完成的事務T1的記錄(605)，因為事務-伺服器關係已經撤消。bean存儲區包含(602)會話bean鍵(B1)和其更新的會話狀態(beans＝2)，表示bean實例在事務完成期間被鈍化。
圖6中的第四狀態是在bean管理事務尚末完成的情況下，在鈍化的bean實例B1已經被從server2訪問之後第三個狀態的繼續。路由表包含(607)bean實例鍵二級B1，以及在其中bean當前是活動的伺服器進程(server2)。此外，bean實例鍵B1包括表示bean在bean管理事務下正在被訪問的標誌。這將確保，下面進行的訪問bean實例的嘗試將被路由到server2。bean存儲區沒有現在處於活化狀態的bean實例B1的記錄(608)。此狀態將一直保留，直到bean管理事務完成，此時，bean將被鈍化，狀態將返回到等價於圖6中的第三個狀態的狀態，其中，路由文件不再具有bean鍵的記錄，bean存儲區包含會話bean實例。
圖4所示的狀態構成了優選實施例中的可能的所有狀態(一個除外)。沒有顯示的狀態是路由表不包含bean實例的鍵或在其中事務正在被訪問並且bean存儲區不包含bean實例的記錄的事務的ID。此狀態可以通過bean實例不存在或bean實例在超出事務的範圍的一個伺服器進程中處於活化狀態或作為容器管理事務的一部分來實現。
因此，顯示了，在本發明的優選實施例中，會話bean實例在一個事務完成時被鈍化，被鈍化的bean實例的序列化形式在重新活化時從bean存儲區刪除。結果，在重新活化之後，只有bean實例的狀態的表示位於易失性存儲器中的重新活化的bean實例中。這確保了，會話bean實例只能存在於一個位置，只能在完成的事務性狀態從不同的伺服器進程進行訪問，如果在事務完成之前從失敗的伺服器進程在一個事務中進行訪問，則無法訪問。這就保證了，如果未提交的事務性的更新丟失，就無法訪問有狀態會話bean，結果，有狀態會話bean實例中的可訪問的狀態始終反映所有更新。如果如此嘗試訪問已經無法訪問的有狀態會話bean實例，則請求者將收到一個相應的異常，如java.rmi.NosuchObjectException。
圖7顯示了根據本發明的優選實施例的當向伺服器進程分配入站請求時工作負荷管理單元所遵循的邏輯。在步驟701中，進行檢查，以查看請求是否為事務性的。如果請求是事務性的，則從請求中獲取事務ID，並在步驟702中，將該ID與路由表中的事務ID進行比較。如果找到ID，則在步驟703中，將請求分配給路由表中指定的伺服器進程。如果未找到ID，則在步驟704中，將請求分配給工作組中任何伺服器進程。如果請求不是事務性的，則在步驟705中，進行檢查，以查看請求是否指向在bean管理事務下正在被訪問的bean實例。此信息位於bean實例的鍵中的標誌中。如果是這種情況，則從請求獲取bean實例的鍵，並在步驟706中，將該ID與路由表中的bean實例鍵進行比較。如果找到該鍵，則在步驟707中，將請求分配給路由表中指定的伺服器進程。如果未找到該鍵，則在步驟704中，將請求分配給工作組中任何伺服器進程。如果bean實例的鍵沒有指出bean實例在bean管理事務下正在被訪問，則不對路由表進行搜索，並在步驟704中將請求分配給任何伺服器。
請注意，在bean實例的鍵中使用標誌以指出bean實例在bean管理事務下正在被訪問，是一種性能優化方法。在優選實施例中，如果bean鍵在bean管理事務下正在被訪問，那麼，它將只位於路由表中。結果，使用標誌意味著，如果bean實例的鍵沒有設置標誌，則沒有必要搜索路由表。如果沒有使用標誌，則對於指向bean實例的所有入站請求的所有bean實例鍵，都必須檢查路由表。
值得注意的是，優選實施例使用了與CORBA兼容的OTS事務作為表示工作單元的方式。然而，本發明還可以應用於其他類型的工作單元，如不同類型的事務、會話、業務方法、客戶端請求，或將一個或多個事件組合到一個單元的任何其他方式。這可以通過在所選的工作單元完成時鈍化有狀態會話bean實例來實現。此外，某些實施例可以使用工作單元的層次結構。例如，在其中OTS事務是所選的工作單元的優選實施例中所描述的系統中，在沒有事務的情況下，也可以使用業務處理方法作為工作單元。如果客戶端超出事務範圍請求業務方法，並且業務方法直接或間接地訪問有狀態會話bean實例，那麼，可以在業務方法完成時鈍化有狀態會話bean實例。優選情況下，這將在客戶端調用的業務方法的postInvoke處理期間進行。然後，這為涉及有狀態會話bean實例的客戶端調用的業務方法提供工作負荷管理。
值得進一步指出的是，在優選實施例中，選擇了有狀態會話bean作為在存儲器中維護會話狀態的程序實體類型的優選實施例。然而，本發明可以應用於需要工作負荷管理支持的在存儲器中維護狀態的任何類型的實體，如Java bean或C++對象。
優選情況下，本發明作為與計算機系統一起使用的電腦程式產品來實現。這樣的實現方式可以包括固定在諸如計算機可讀的介質(例如，磁碟、CD-ROM、ROM或硬碟)之類的有形介質，或通過數據機或其他接口設備，通過有形的介質(包括而不僅限於，光學或模擬通信線路)，或使用無線技術(包括而不僅限於，微波、紅外線或其他傳輸技術)可傳輸的到計算機系統的一系列計算機可讀的指令。一系列計算機可讀的指令實現了前面所描述的功能的全部或一部分。
那些精通本技術的人將理解，這樣的計算機可讀的指令可以以許多程式語言編寫，以便與許多計算機體系結構或作業系統一起使用。此外，這樣的指令可以使用任何存儲技術來進行存儲，當前的或未來的，包括而不僅限於，半導體、磁性、或光學，或使用任何通信技術，當前的或未來的，包括而不僅限於，光學、紅外線或微波。可以預期，這樣的電腦程式產品可以作為可移動介質附帶列印或電子文檔來進行分發，例如，包裝的軟體，預裝到計算機系統中，例如，裝到系統ROM或硬碟中，或從伺服器或電子公告板通過網絡(例如，網際網路或全球資訊網)進行分發。
權利要求
1.在具有非易失性存儲器存儲設備和至少一個伺服器的能夠運行伺服器進程的數據處理系統中，一種對程序實體進行數據處理的方法，包括下列步驟作為第一伺服器進程的一部分，通過將程序實體的實例寫入到所說的存儲設備上的程序實體存儲區，並從所說的伺服器進程中將其刪除，來鈍化所說的程序實體的實例；作為第二伺服器進程的一部分，通過從所說的程序實體存儲區讀取所說的程序實體的所說的實例，並在所說的伺服器進程中重新創建它，來重新活化所說的程序實體的所說的實例；以及根據工作負荷分配算法選擇在其中重新活化所說的程序實體實例的伺服器進程。
2.根據權利要求1所述的方法，其中，所說的鈍化伺服器進程代表在其中訪問所說的程序實體實例的客戶端執行工作單元，所說的鈍化步驟在完成所說的工作單元時鈍化所說的程序實體實例。
3.根據權利要求2所述的方法，其特徵在於，所說的工作單元包括事務。
4.根據權利要求2所述的方法，其特徵在於，所說的工作單元包括業務方法。
5.根據前面的任何一個權利要求所述的方法，其特徵在於，所說的程序實體包括有狀態會話bean。
6.根據權利要求2到4中的任何一個權利要求所述的方法，其特徵在於，所說的重新活化步驟從所說的程序實體存儲區讀取所說的程序實體的所說的實例並將其刪除，從而確保，如果所說的程序實體實例在所說的工作單元下重新活化，則在直到所說的工作單元完成之前無法從所說的工作單元外面重新訪問它。
7.根據權利要求1到4中的任何一個權利要求所述的方法，進一步包括下列步驟在所說的存儲設備上維護一個路由表中程序實體實例位置信息，其特徵在於，所說的路由表用於定位許多程序實體實例，所說的信息表示程序實體實例在所說的許多伺服器進程中的某一個中是處於活化狀態，還是在所說的程序實體存儲區處於鈍化狀態。
8.根據權利要求7所述的方法，進一步包括下列步驟將一個鍵與所說的許多程序實體實例中的至少一個關聯，用於將所說的至少一個程序實體實例標識為請求的目標，其中，所說的鍵包括一個標誌，表示所說的至少一個程序實體實例的位置信息在所說的路由表中存在。
9.一種存儲在計算機可讀的存儲介質上的電腦程式產品，用於具有非易失性存儲器存儲設備和至少一個伺服器的能夠運行伺服器進程的數據處理系統中，所說的產品包括指令，當執行這些指令時，導致所說的系統通過執行下列步驟來處理程序實體作為第一伺服器進程的一部分，通過將程序實體的實例寫入到所說的存儲設備上的程序實體存儲區，並從所說的伺服器進程中將其刪除，來鈍化所說的程序實體的實例；作為第二伺服器進程的一部分，通過從所說的程序實體存儲區讀取所說的程序實體的所說的實例，並在所說的伺服器進程中重新創建它，來重新活化所說的程序實體的所說的實例；以及根據工作負荷分配算法選擇在其中重新活化所說的程序實體實例的伺服器進程。
10.根據權利要求9所述的電腦程式產品，其中，所說的鈍化伺服器進程代表在其中訪問所說的程序實體實例的客戶端執行工作單元，所說的鈍化步驟在完成所說的工作單元時鈍化所說的程序實體實例。
11.根據權利要求10所述的電腦程式產品，其特徵在於，所說的工作單元包括事務。
12.根據權利要求10所述的電腦程式產品，其特徵在於，所說的工作單元包括業務方法。
13.根據權利要求9到12中的任何一個權利要求所述的電腦程式產品，其特徵在於，所說的程序實體包括有狀態會話bean。
14.根據權利要求10到12中的任何一個權利要求所述的電腦程式產品，其特徵在於，所說的重新活化步驟從所說的程序實體存儲區讀取所說的程序實體的所說的實例並將其刪除，從而確保，如果所說的程序實體實例在所說的工作單元下重新活化，則在直到所說的工作單元完成之前無法從所說的工作單元外面重新訪問它。
15.根據權利要求9到12中的任何一個權利要求所述的電腦程式產品，進一步包括下列步驟在所說的存儲設備上一個路由表中維護程序實體實例位置信息，其特徵在於，所說的路由表用於定位許多程序實體實例，所說的信息表示程序實體實例在所說的許多伺服器進程中的某一個中是處於活化狀態，還是在所說的程序實體存儲區處於鈍化狀態。
16.根據權利要求15所述的電腦程式產品，進一步包括下列步驟將一個鍵與所說的許多程序實體實例中的至少一個關聯，用於將所說的至少一個程序實體實例標識為請求的目標，其特徵在於，所說的鍵包括一個標誌，表示所說的至少一個程序實體實例的位置信息在路由表中存在。
17.一種數據處理系統，包括至少一個伺服器；許多能夠在所說的至少一個伺服器上運行的伺服器進程，其中每個伺服器進程都支持程序實體；以及每一個伺服器進程都可以訪問到的非易失性存儲器存儲設備；其中，每一個伺服器進程都包括用於通過將所說的程序實體的實例寫入到所說的存儲設備上的程序實體存儲區來鈍化所說的程序實體的實例的裝置；用於通過從所說的程序實體存儲區讀取所說的程序實體的實例，並使用它來重新創建所說的程序實體實例，來重新活化所說的程序實體的實例的裝置；所說的用於重新活化的裝置能夠重新活化被不同的伺服器進程的鈍化裝置鈍化的程序實體實例；以及用於根據工作負荷分配算法選擇在其中重新活化所說的特定程序實體實例的伺服器進程的裝置。
18.根據權利要求17所述的數據處理系統，所說的許多伺服器進程中的每一個都進一步包括用於代表在其中訪問所說的程序實體的第一個實例的客戶端執行工作單元的裝置；其中，所說的用於鈍化所說的程序實體實例的裝置在所說的工作單元完成時鈍化所說的第一個程序實體實例。
19.根據權利要求18所述的數據處理系統，其特徵在於，所說的工作單元包括事務。
20.根據權利要求18所述的數據處理系統，其特徵在於，所說的工作單元包括業務方法。
21.根據權利要求17到20中的任何一個權利要求所述的數據處理系統，其特徵在於，所說的程序實體包括有狀態會話bean。
22.根據權利要求18到20中的任何一個權利要求所述的數據處理系統，其特徵在於，所說的重新活化裝置從所說的程序實體存儲區讀取所說的程序實體的實例並將其刪除，從而確保，如果所說的重新活化裝置在所說的工作單元中重新活化所說的第一個程序實體實例，則在直到所說的工作單元完成之前無法從所說的工作單元外面重新訪問所說的第一個程序實體實例。
23.根據權利要求17到20中的任何一個權利要求所述的數據處理系統，所說的許多伺服器進程中的每一個都進一步包括用於在所說的存儲設備上維護一個路由表中程序實體實例位置信息的裝置，其中，所說的路由表用於定位許多程序實體實例，所說的信息表示程序實體在所說的許多伺服器進程中的某一個中是處於活化狀態，還是在所說的程序實體存儲區處於鈍化狀態。
24.根據權利要求23所述的數據處理系統，每一個伺服器進程都進一步包括用於將一個鍵與一個程序實體實例關聯的裝置，用於將所說的程序實體實例標識為請求的目標，其中，所說的鍵包括一個標誌，表示所說的至少一個程序實體實例的位置信息在路由表中存在。
全文摘要
在包括許多伺服器進程的工作負荷管理系統中，每一個伺服器進程都能夠支持一個給定的程序實體，如，Enterprise JavaBeans
文檔編號G06F9/46GK1516831SQ02807390
公開日2004年7月28日 申請日期2002年3月7日 優先權日2001年3月29日
發明者安德魯·S·克萊門特, 安·E.·多爾頓, 巴裡·迪克恩森, 託馬斯·J.·弗路恩德, 喬納森·P.·H.勞倫斯, 伊恩·J.·米切爾, 格林·諾明頓, 史蒂文·普威爾, 安索尼·斯多瑞, J. 弗路恩德, P. H.勞倫斯, 多爾頓, 斯多瑞, 普威爾, J. 米切爾, 安德魯 S 克萊門特, 諾明頓, 迪克恩森 申請人:國際商業機器公司