重定序兩階段提交中的資源的最後代理優化方法和系統的製作方法
2023-05-17 05:12:36
專利名稱：重定序兩階段提交中的資源的最後代理優化方法和系統的製作方法
技術領域：
本發明涉及事務處理，尤其涉及兩階段提交(two-phase commit)中的最後代理優化(last-agent optimization)。
背景技術：
任何涉及需要均一結果(homogeneous outcome)的多個實體的操作均需要某種外部協同以保證每個實體接收相同結果。分布式事務是這種操作的一個例子。事務一般具有兩個可能結果提交或回退。為了保證結果均一，使用被稱為兩階段提交的協議。管理事務資源的實體被稱作資源管理器。
在兩階段提交過程中，首先請求編入(enlist)事務的每個資源準備提交，並且接著被指示進行提交。在第一階段期間，資源管理器確認它能夠通過應答一個認可值來成功完成提交。如果所有資源認可提交，則寫入一個日誌記錄以指示結果並且提交所有資源。如果任何資源不能確認提交將成功，則所有資源被回退。如果結果是回退，則由於預設結果是回退(假定中止)，通常沒有日誌記錄被寫入。當所有資源成功地執行相同結果時，所述結果被稱為是原子的(atomic)。
事務管理器通常負責組合和定序要驅動的資源。假定進行準備，提交和回退的每個調用必須被驅動到網絡上的從屬資源，則兩階段事務導致網絡上的一個日誌寫入和2n個調用，其中n是編入事務中的資源的數量。
如果只有一個資源被編入事務，則準備階段和日誌寫入變得不必要，因為只有一個資源，並且因此無論準備調用是否成功，事務的結果將是原子的。在這種情況下，簡單請求單個資源進行提交，並且提交總體結果。如果提交失敗，則總體結果變為回退。這種優化被稱作一階段提交或純代理(only-agent)。
需要進一步優化將通常需要兩階段提交的選擇事務收縮為一階段提交的兩階段提交過程(也稱為最後代理優化)。當請求準備時，資源會在其對於後續提交或回退調用沒有要完成的更新的情況下，返回只讀值。如果在事務中編入n個資源，並且前n-1個資源對準備調用表決為只讀，則剩餘資源將變成編入的唯一資源，並且能夠對其執行一階段提交。這個所需的優化被稱作最後代理優化，因為最後資源(或代理)會能夠執行一階段提交優化並且仍然保持總體事務的均一結果。在這種情況下，提交事務所需的網絡調用的總數將減少到n，並且在準備階段之後不需要記入日誌。
發明內容
本發明涉及對參與兩階段提交的資源進行動態重定序以啟發式地進行最後代理優化的方法，系統和存儲介質。
第一方面用於最後代理優化的方法。針對應用程式的多個資源中的每個資源建立連接。確定當前事務上下文。收集與每個資源相關的使用統計數據。啟發式地確定當前事務上下文中每個資源的順序以實現至少部分地基於使用統計數據的最後代理優化。另一個方面是存儲執行這個方法的指令的存儲介質。
另一個方面是用於最後代理優化的系統，其包含直方圖和事務管理器。直方圖保存多個資源中的每個資源的使用統計數據和歷史信息。事務管理器至少部分地基於直方圖對當前事務中的每個資源進行定序，使得只讀資源被首先準備，並且無需準備便提交單純非只讀資源(sole non-read-only resource)。
另一個方面是用於最後代理優化的另一個系統，其包含應用伺服器，容器，事務管理器和連接管理器。應用伺服器在通用計算機上運行。容器也駐留在伺服器上。至少一個應用程式正在容器中運行。應用程式包含使用多個資源的至少一個事務。伺服器上的連接管理器提供資源給應用程式，並且由事務管理器編入資源。伺服器上的事務管理器在兩階段提交過程的提交階段期間啟發式地對資源進行定序以實現最後代理優化。
另一個方面是存儲用於執行最後代理優化方法的指令的存儲介質，其中使用統計數據被存儲在直方圖中。使用直方圖對當前事務上下文中的資源進行定序以實現最後代理優化。自主調整定序以在使用方面產生變化。
結合以下描述，所附權利要求書和附圖，本發明的這些和其它特徵，方面及優點將更好理解，其中圖1是兩階段提交過程的現有技術例子的數據流圖；圖2是優化的最後代理提交過程的示例性實施例的數據流圖；圖3是事務系統的示例性實施例的模塊圖；圖4是將資源編入當前事務的處理的示例性實施例的數據流圖；圖5是圖解示例性實施例如何針對多個應用程式跟蹤資源的使用統計數據的邏輯圖；及圖6是優化準備處理的資源定序的示例性實施例的流程圖。
具體實施例方式
圖1示出兩階段提交過程的現有技術例子，其中沒有為最優提交而對資源進行定序。在第一和第二步驟中，來自應用程式容器和應用程式管理器的提交流向事務。在事務中存在兩個資源。在第三步驟中，第一資源接收準備調用，並且向事務返回認可。在第四步驟中，第二資源接收準備調用，並且向事務返回只讀。這結束了兩階段提交的第一階段。由於資源中的一個返回認可，所以在第五步驟中結果被記錄，並且在第六步驟中，提交在該資源(第一資源)上流過，對此第一資源返回認可。這結束了兩階段提交的第二階段。
在這個例子中，通常需要兩階段提交的選擇事務被縮減為一階段提交。當請求準備時，資源在其對後續提交或回退調用沒有要完成的更新的情況下，返回只讀值。如果在事務中編入n個資源，並且前n-1個資源對準備調用表決為只讀，則剩餘資源變成編入的唯一資源，並且執行一階段提交。這是最後代理優化，因為最後資源(或代理)能夠執行一階段提交優化。在這種情況下，提交事務所需的網絡調用的總數減少到n，並且在準備階段之後不必記錄。
如果最後資源之前的所有資源表決為只讀，則可以執行最後代理優化。例如，假定事務編入n個資源，其中n＞1。如果第一個資源對準備調用表決認可，並且剩餘n-1個資源表決只讀，則僅留下一個編入事務中的資源。然而，這個資源已經為準備而驅動。由於兩階段提交中的階段一已經執行，所以不能執行一階段提交。隨著兩階段提交的第二階段，結果被記錄，並且驅動剩餘資源進行提交。在這種情況下，由於一個資源被準備以及提交，所以存在總共n+1個提交事務所需的網絡調用。
在這個示例性實施例中，如果資源被最優定序，則額外網絡調用和日誌寫入在上述情景中是可避免的。如果不能表決只讀的資源被最後驅動，則在使用最後代理優化時不需要額外網絡調用和日誌寫入。
圖2示出了優化的最後代理提交過程的示例性實施例。圖1所示的相同事務在圖2中示出。然而，在圖2中，資源被定序，使得在第一階段期間，第二資源被首先驅動。在第三步驟中，響應準備調用，第二資源返回只讀。由於只有一個資源，即第一資源留下，在第四步驟中，它被驅動提交，而無需執行階段一的剩餘部分。
事務處理的例子是儲蓄帳戶和支票帳戶之間資金的轉移。在存在系統故障的情況下，兩階段提交操作可以被用於進行恢復。假定存在從儲蓄帳戶傳送$100到支票帳戶的請求。為了滿足請求，$100必須從儲蓄帳戶中扣除。如果從儲蓄帳戶中扣除$100，但是在$100記入到支票帳戶之前系統失敗，則存在問題。兩階段提交操作包含向資源(例如儲蓄帳戶管理器和支票帳戶管理器)通知需要從儲蓄帳戶轉移$100到支票帳戶，並且在存儲用於可能的恢復的事務記錄的同時請求其它資源的批准。一旦存在批准並且所有方面均沒有問題，則事務被提交並且資源有責任完成事務，即使存在系統失敗(在這種情況下，所存儲的記錄在系統重新啟動之後被用於完成事務)。
當事務中只有一個更新方或一個資源留下時，可以執行最後代理優化。不需要請求唯一一個資源進行提交。假定事務是儲蓄帳戶的餘額查詢；即一個資源(儲蓄帳戶管理器)的只讀事務。當詢問儲蓄帳戶管理器是否能夠提交時，它響應以忘記(forget)。
示例性實施例自動確定順序，使得在指定上下文中可能表決認可的任何資源之前輪詢在指定上下文中可能表決忘記的任何資源。首先確定所有只讀動作，把提交者留到最後。最優的情況是僅留有一個提交者。基於可以顯示在直方圖中的使用數據進行關於資源是否可能表決忘記或提交的預測。
圖3示出事務系統的示例性實施例。應用伺服器300包含應用程式容器302，連接管理器304及事務管理器306。例如應用伺服器300的應用伺服器是任何通用計算機。
應用程式容器302擁有第一應用程式308和第二應用程式310。例如應用程式容器302的應用程式容器是用戶能夠部署要運行的應用程式的地方。應用程式容器是受管理的環境，其中應用程式具有對它可用的某些服務，例如連接管理和事務管理。根據怎樣定義受管理的環境，應用程式能夠具有變化的粒度，例如部件級別。在這個例子中，第一應用程式308是獨立應用程式，同時第二應用程式310包含第一模塊312和第二模塊314。
連接管理器304包含第一資源(A)316和第二資源(B)318。
事務管理器306從各個資源收集表決，並且確定結果。事務管理器306負責對資源進行定序，其對應用程式308，310透明。用於對參與兩階段提交的資源進行動態重定序以啟發式地進行最後代理優化的示例性實施例駐留在事務管理器306中。在這個示例性實施例中，使用散列映射將使用統計數據存儲在事務管理器306中。在其它示例性實施例中，使用統計數據被存儲在事務管理器306可訪問的任何存儲設備中。
假定第一資源316是儲蓄帳戶，並且第二資源318是支票帳戶。並且，假定第二應用程式310中的第一模塊312對儲蓄帳戶執行餘額查詢，即只讀操作，並且第二模塊314對支票帳戶執行提取(withdrawal)，即修改該資源。在這種情況下，期望基於使用統計數據對資源316，318進行定序，使得只讀事務(餘額查詢)首先進行，並且修改事務(提取)最後進行。
為了使事務管理器306使用最後代理優化對資源進行定序，事務管理器306需要先驗地知道資源在它們被驅動進行準備時將怎樣表決。在某些系統中，系統管理員可以提供部署提示給事務管理器以指示特定資源將怎樣作為。這允許事務管理器306將可能表決只讀的資源定序在從不表決只讀的那些資源之前。然而，這需要系統管理員可得到這個信息，並且需要使用這個資源的所有應用程式以類似方式使用它，因為多個應用程式可能以不同方式使用相同資源，因而需要相同資源的多個配置。由於工作負載模式可表現出隨時間變化特性，即使在系統的配置沒有改變時也是如此，因此對於某些安裝，這是不切實際的。
圖4示出了用將資源編入當前事務的處理的示例性實施例。在第一步驟中，應用程式容器302內的第一應用程式308正調用連接管理器304以建立到一資源，例如保存銀行帳戶的關係資料庫的連接。在第二步驟中，連接管理器304調用應用程式容器312以檢索應用程式標識符(ID)。應用程式標識符是在應用程式容器302內為第一應用程式308部署的標識符。作為響應，應用程式容器312返回ID＝1。在步驟三，連接管理器304通過事務管理器306進行檢查以確定第一應用程式308是否具有事務上下文。它有，所以在步驟四連接管理器304編入第一資源(A)316。在步驟五，當前事務通過事務管理器306進行檢查以得到到目前為止針對第一資源(A)316產生的使用統計數據，並且返回到連接管理器304。
在這個例子中，″A1″是應用程式名稱(應用程式″1″)和資源名稱(資源″A″)的組合。其它示例性實施例可以使用任何其他唯一標識符。在圖3中，第二應用程式310具有兩個部件，第一模塊312和第二模塊314。為了跟蹤特定應用程式和特定資源的正確使用統計數據，指示第二應用程式310正使用第一資源316是不夠的。而是，事務管理器306通過容器管理器304進行檢查以確定哪個部件正在運行。在這種情況下，它是第一應用程式308。接著，當連接管理器304正編入第一資源316時，連接管理器304向事務傳遞應用程式ID″1″和資源ID″A″。事務連接它們以產生″A1″，以便確定正確部件的使用統計數據。部件的粒度取決於維護ID列表和目前運行的應用程式的ID的應用程式容器302。例如，在Java2平臺中，企業版(J2EE)伺服器，應用程式被分解成模塊，並且模塊被分解成部件，即3個粒度級別。在其它示例性實施例中，可以有或多或少的粒度級別。
圖5圖解了示例性實施例如何針對多個應用程式跟蹤資源的使用統計數據。對於第一資源(A)316，存在3個部件的使用統計數據，即第一應用程式308(ID＝A1)，第二應用程式310的第一模塊312(ID＝A2.1)和第二應用程式310的第二模塊314(ID＝A2.2)。
所有這些部件500，502，504的資源統計數據均包含準備，只讀和失敗的計數，以及只讀(RO)和失敗的等級。只讀等級＝準備數量/只讀數量。只讀等級1是最高可能等級，指示每次只讀的表決。失敗等級＝準備數量/失敗數量，其中失敗指示遠程資源管理器在準備期間遇到例如處理XA異常(XAException)的某種異常條件。這裡，由於它與ID-A1的準備數量(準備＝100)相同，所以失敗等級100是ID＝A1的最高可能等級。
圖6示出了優化準備處理的資源排序的示例性實施例。這個示例性實施例包含確定怎樣排序編入事務中的資源，使得結果排序產生如上所述的最後代理優化。該方法無需系統管理員的幹預動態對資源進行定序。
在這個示例性實施例中，為了預測資源的將來行為，在直方圖中跟蹤每個資源的以往行為。直方圖是存儲器中存儲的表格，使用情況的表格和歷史記錄。當情況出現時，搜索表格以查看它是否在以前出現過。直方圖記錄針對指定系統和情況資源表決只讀或無法完成準備階段的頻度。事務管理器使用這個信息預測在當前事務中資源可能怎樣作為，並且對資源進行定序，使得可能表決只讀的那些資源被首先驅動。這增加了能夠執行最後代理優化的頻率。
在這個示例性實施例中，直方圖包含資源實例到使用統計數據的映射。在使用統計數據中，若干計數器被維護。一個計數器表示這個資源已經準備過的總次數。另一個計數器表示這個資源已被表決只讀的總次數。另一個計數器表示這個資源在準備階段內出現異常的總次數。使用這些計數器，資源實例按照相對於準備總數的表決只讀頻度和相對於準備總數無法完成準備頻度進行排序。
在另一個示例性實施例中，應用伺服器在通用計算機上運行。應用伺服器包含容器，連接管理器和事務管理器。在容器內，部署和運行一或多個應用程式。連接管理器負責向容器中運行的應用程式提供資源實例，並且通過事務管理器編入那些資源。事務管理器負責產生容器中運行的應用程式的事務邊界，提供編入事務邊界的資源的原子結果，並且在提交階段對資源進行定序。
在這個示例性實施例中，當部署應用程式時，它被分配應用ID。根據怎樣構造應用程式，這個應用ID被進一步分解成應用程式內的部件。應用程式內的每個部件也基於應用程式的總體ID被分配ID。應用程式內的每個部件提供描述部件事務語義的部署元數據。元數據描述部件是否應當在事務內運行，及部件是否應當加入可能在其進入時已經運行的事務。
在這個示例性實施例中，當應用程式被驅動時，容器檢查部件的元數據並且把這個請求所需的事務上下文通知事務管理器。接著執行應用程式代碼。當應用程式需要使用資源(例如，一部分關係資料庫)時，應用程式通過連接管理器請求連接。連接管理器檢查當前事務上下文，並且在存在事務的情況下，連接管理器向事務管理器傳遞資源和當前執行的部件的ID。事務管理器接收資源實例並且把它轉換成標識符，該標識符與部件的ID連接以產生表示資源和使用資源的部件的標識符。
在這個示例性實施例中，存在實現為把標識符映射到一組使用統計數據的散列映射的直方圖。通過把部件ID和資源ID連接在一起，我們具有每個資源的多組使用統計數據，使用資源的每個部件有一組。使用統計數據與資源實例結合，並且共同被編入當前事務。接著，連接管理器把到資源的連接返回到應用程式代碼。
在這個示例性實施例中，使用統計數據包含通過將準備總數除以只讀表決總數而產生的只讀等級。每次100％表決只讀的資源具有等級值1，其是用於優化的最優可能等級。每次0％表決只讀表決只讀的資源具有等於它已經準備的總次數的等級。通過將準備總數除以失敗或異常總數來確定失敗等級。具有高等級的資源被排序在具有低等級的資源之前。每次100％失敗的資源具有等級1。
在某些實施例中，所有計數器被初始化成1以防止在計算等級時除以0。在某些實施例中，當進行變化以允許配置改變快速反映在使用統計數據中，或反映在任何其他適當時間安排上時，在指定時間間隔復位計數器和等級。在某些實施例中，如果準備計數器達到系統的最大值，則等級和計數器被復位。
在某些實施例中，等級僅在指定間隔被計算。在某些實施例中，對於前100個準備，每次準備總數遞增時計算等級。對於接著的100個準備，每十次準備總數遞增時計算等級。對於接著的10,000個準備，每100次準備遞增時計算等級。對於所有剩餘的準備，在某些實施例中，每1000次準備遞增時計算等級。
在這個示例性實施例中，使用統計數據被封裝在插入排序列表的對象中。排序列表接收兩個比較器對象中的一個。比較器對象基於只讀等級或失敗等級排序使用統計數據。
在這個示例性實施例中，當部件結束執行時，容器再次檢查部件的元數據以確定當前事務上下文是否已經結束。如果事務上下文結束，則容器聯繫事務管理器以完成事務。事務管理器基於相關的使用統計數據對象排序編入事務中的資源。只讀比較器把具有低只讀等級的資源放置在列表的開始處。
在這個示例性實施例中，事務管理器基於其等級驅動每個資源的準備。當準備被驅動時，資源的準備計數器遞增。當資源表決只讀時，該資源的只讀計數器遞增，並且該資源被從編入事務中的資源的列表中清除。在所有表決之後，如果單個資源保持編入，則執行最後代理優化以結束事務。如果響應準備調用，資源表決認可，則列表的比較器切換到失敗比較器，按照其失敗等級排序剩餘元素，使得可能失敗的資源被首先驅動。如果資源失敗，則由於結果現在為回退，所以不需要在剩餘資源上驅動準備。在那些不太可能失敗的資源之前排序可能失敗的資源在實際失敗情況下額外節省了流過網絡的若干準備，然而這應當只在唯一代理優化不再可能時進行。兩階段提交接著繼續對剩餘資源進行。如果資源失敗，則其失敗計數遞增，並且由於資源將被回退，所以跳過剩餘資源的準備階段。
如上所述，本發明的實施例可以實現這些處理的計算機實現的處理和設備的形式體現。本發明的實施例也可以包含以例如軟盤，CD-ROM，硬碟驅動器或任何其他計算機可讀存儲介質的有形介質體現的指令的電腦程式代碼的形式體現，其中，當電腦程式代碼被載入並且通過計算機執行時，計算機變成實踐本發明的設備。本發明也可以電腦程式代碼的形式體現，例如在存儲介質中存儲，載入和/或通過計算機執行，或通過例如電連線或電纜，光纖，或電磁輻射的某種傳輸介質發送的電腦程式代碼，其中當電腦程式代碼被載入並且通過計算機執行時，計算機變成實踐本發明的設備。當在通用微處理器上實現時，電腦程式代碼段配置微處理器以產生特定邏輯電路。
雖然參照示例性實施例描述了本發明，然而本領域的技術人員將理解，在不偏離本發明的範圍的情況下可以進行各種變化並且可以用等同特徵代替其中的要素。另外，本發明的各種實施例的較小調整可以使用對標準的將來改進或變化。此外，各種部件可以硬體，軟體或固件或其任何組合實現。最終，可進行許多修改以使特定情況或材料適合本發明的教導，而無需偏離其實質範圍。因此，本發明不限於公開為本發明具體實施方式
的特定實施例，本發明將包含屬於所附權利要求書的範圍的所有實施例。此外，術語第一，第二等等的使用不表示任何順序或重要性，而是術語第一，第二等等被用於把一個要素與另一個要素區分開。此外，術語一，一個等等的使用不表示數量的限定，而是表示至少一個所指項目的存在。
權利要求
1.一種用於最後代理優化的方法，包括建立到應用程式的多個資源中的每個資源的連接；確定當前事務上下文；收集與每個資源相關的使用統計數據；及啟發式地確定當前事務上下文中每個資源的順序以實現至少部分地基於使用統計數據的最後代理優化。
2.如權利要求1所述的方法，其中與每個資源相關的使用統計數據包含從以下之中選出的至少一個計數器這個資源被準備過的次數，這個資源被表決過為只讀的次數，及這個資源失敗過的次數。
3.如權利要求2所述的方法，其中與每個資源相關的使用統計數據包含只讀等級及失敗等級。
4.如權利要求3所述的方法，其中以選定間隔確定只讀等級及失敗等級。
5.如權利要求2所述的方法，還包括檢索與應用程式相關的應用程式標識符；其中散列映射把應用程式標識符映射到該應用程式的使用統計數據。
6.如權利要求2所述的方法，其中至少一個計數器被周期性地復位。
7.如權利要求1所述的方法，其中使用統計數據被封裝在插入排序列表的對象中。
8.如權利要求3所述的方法，還包括基於與該資源相關的只讀等級驅動每個資源上的準備；在編入資源的列表中編入每個資源；從當前事務上下文的編入資源列表中清除只讀資源；對單個編入資源執行最後代理優化。
9.一種用於最後代理優化的系統，包括用於保存多個資源中的每個資源的使用統計數據和歷史信息的直方圖；及事務管理器，用於至少部分地基於直方圖對當前事務中的每個資源進行定序，使得只讀資源被首先準備，並且無需準備地提交單純的非只讀資源。
10.如權利要求9所述的系統，其中事務管理器啟發式地確定當前事務中的每個資源的順序以實現最後代理優化。
11.一種用於最後代理優化的系統，包括在通用計算機上運行的應用伺服器；駐留在伺服器上的容器；在容器中運行的至少一個應用程式，應用程式包含使用多個資源的至少一個事務；伺服器上的事務管理器，用於在兩階段提交過程的提交階段期間啟發式地對資源進行定序以實現最後代理優化；及伺服器上的連接管理器，用於提供資源給應用程式並且用於使用事務管理器編入資源。
12.如權利要求11所述的系統，其中事務管理器產生應用程式的事務邊界。
13.如權利要求12所述的系統，其中事務管理器提供編入事務邊界的資源的原子結果。
14.如權利要求11所述的系統，其中事務管理器基於動態使用統計數據對資源進行定序。
15.如權利要求14所述的系統，其中使用統計數據被存儲在散列映射中。
16.如權利要求11所述的系統，其中事務管理器基於歷史信息對資源進行定序。
17.如權利要求11所述的系統，其中事務管理器如此對資源進行定序，使得響應準備調用而可能表決為只讀的任何資源被放置在其它資源之前。
18.一種存儲有用於執行最後代理優化方法的指令的存儲介質，包括在直方圖中存儲使用統計數據；使用直方圖對當前事務上下文中的多個資源進行定序，以實現最後代理優化；及自主調整定序以在使用中產生變化。
全文摘要
產生和維護多個資源的直方圖或資源狀態歷史表。事務或資源管理器基於直方圖將各個資源安排和/或重定序成一個序列，使得只讀資源被首先準備，並且單純非只讀資源不需要準備，而是只需要提交。事務管理器啟發式地確定驅動資源的順序以實現最後代理優化。直方圖基於運行時刻和應用程式上下文保持與上下文相關，以保證按上下文的使用模式被優化，而無需設備了解任何使用模式。
文檔編號G06F9/46GK1794181SQ200510124679
公開日2006年6月28日 申請日期2005年11月14日 優先權日2004年12月21日
發明者斯特凡·J·金德爾, 馬修·J·塞克斯, 蒂莫西·D·卡金斯基 申請人:國際商業機器公司