事務處理系統的製作方法
2023-04-24 17:41:46
專利名稱：事務處理系統的製作方法
技術領域：
本發明涉及處理事務處理系統中的作業(work)單元的方法，並且涉及該系統本身。在一種實施方式中，本發明提供了帶有診斷的事務的自動重試。
背景技術：
在計算中，事務處理是一種類型的信息處理，其中操作被分成單獨的、不可分割的作業單元，稱為事務(transaction)。每個事務必須作為一個完整的單元成功或失敗，而不能停留在中間狀態。事務處理被設計成將計算機系統，諸如資料庫，維持在已知的一致狀態。這是通過以下事實來維持的在系統上執行相互依賴的任何操作，要麼全部成功地完成，要麼全部成功地被取消。例如，涉及從一個客戶的儲蓄帳戶把錢移到一個客戶的銀行帳戶的典型銀行事務對銀行來說就是單個事務，但是就計算而言它涉及至少兩個單獨的操 作。這些操作是儲蓄帳戶的貸出和銀行帳戶的計入。從這個例子可以看到，該事務中的所有操作必須或者都成功或者都失敗，從而在銀行的資料庫中決不會存在任何的不一致。事務處理就是設計成提供這個功能。事務處理允許多個單獨的操作自動連結到一起，作為單個、不可分割的事務。事務處理系統確保一個事務中的全部操作都沒有錯誤地完成，或者它們當中沒有一個完成。如果一些操作完成但是在嘗試其它操作時發生錯誤，那麼事務處理系統將退回該事務的全部操作，包括已成功的操作，由此抹去事務的全部蹤跡並把系統恢復到其先前一致的已知狀態。如果一個事務的全部操作都成功地完成了，該事務就由系統提交，而且對資料庫的所有改變都是永久性的。為了檢測系統中錯誤的原因，事務處理系統通常具有可用的診斷功能，其中系統常常每秒執行數千個事務。一種類型的診斷功能是「跟蹤」的使用，這是當一個事務在事務處理系統中執行時對其進行監視，隨著事務的執行，關於該事務的數據以規定的方式存儲在已知的位置。這允許管理員追蹤失敗的任何具體事務的行為，並幫助檢測造成事務失敗的真正原因。為了優化整個事務處理系統的性能，生產事務系統通常配置成具有最少的跟蹤活動。當問題發生時，這使得問題診斷非常困難，而且通常需要用戶重試具體失敗的事務。這既耗時又易於出錯。在許多情況下，問題不能被用戶再現，因為從原始事務被嘗試並失敗之後系統配置將會改變，所以問題將不再發生。但是，這並不意味著問題已經解決，因為以後的變化可能會造成問題再次發生。因此，本發明的一個目的是改進現有的技術。
發明內容
根據本發明的第一方面，提供了一種用於處理事務處理系統中的作業單元的方法，所述系統包括一個或多個生產區域(production region)和一個或多個診斷區域(diagnostic region),其中所述生產區域運行最少的診斷功能或者不運行診斷功能,而所述診斷區域運行最多的診斷功能或者運行全部診斷功能，所述方法包括步驟接收作業單元，把所述作業路由到生產區域，接收所述作業已經失敗的通知，及把所述作業路由到診斷區域。根據本發明的第二方面，提供了一種用於處理作業單元的事務處理系統，包括一個或多個生產區域和一個或多個診斷區域，其中所述生產區域運行最少的診斷功能或者不運行診斷功能，而所述診斷區域運行最多的診斷功能或者運行全部診斷功能，所述系統被布置成接收作業單元，把所述作業路由到生產區域，接收所述作業已經失敗的通知，及把所述作業路由到診斷區域。根據本發明的第三方面，提供了一種計算機可讀介質上的電腦程式產品，所述電腦程式產品用於處理事務處理系統中的作業單元，所述系統包括一個或多個生產區域和一個或多個診斷區域，其中所述生產區域運行最少的診斷功能或者不運行診斷功能，而所述診斷區域運行最多的診斷功能或者運行全部診斷功能，所述電腦程式產品包括用於執行以下動作的指令接收作業單元，把所述作業路由到生產區域，接收所述作業已經失敗的通知，及把所述作業路由到診斷區域。 由於本發明，有可能提供一種事務處理系統，其中存在很少或者沒有會使正在處理作業的生產區域變慢的診斷，但是，當一個事務失敗時，可以對該事務使用診斷，以使得如果作業的重試失敗，可以立即獲得診斷數據。本發明的優點包括改進的失敗診斷，象在繁忙系統上發生的那樣的蹤跡打包(trace wrapping)的可能性較小，附加診斷在無需用戶或操作人員幹預的情況下的自動收集及問題診斷更快更便宜的可能性。由於沒有定義足夠的存儲容量來包含它們，因此蹤跡打包是診斷的損失。事務處理系統被配置成具有TOR (終端/輸入請求所有區域)和多個克隆的AOR(應用所有區域)。用戶請求從TOR被路由到AOR去運行。如果在AOR上發生錯誤，不是讓TOR把錯誤返回給用戶，而是TOR可以自動地重新把該事務路由到啟用了附加或完全診斷的另一個AOR並重試該請求。如果請求工作，這是可以接受的，那麼用戶永遠不需要知道。如果作業失敗，那麼需要充分的診斷來診斷該問題的可能性就更大。優選地，所述方法還包括在接收所述作業已經失敗的通知之後，在把所述作業路由到診斷區域之前，檢查所述診斷區域可用。診斷區域的可用性可以在任何新的重試被發送到該區域之前進行檢查。這將確保不會有太多的重新路由的請求被發送到該診斷區域。如果有多於一個診斷區域在使用當中，那麼作業可以在這多個區域之間平衡，以確保沒有一個區域被重試超載。一般而言，將為一個或多個診斷區域分配低得多的系統資源水平，並因此將以比生產區域慢得多的速度運行。有利地，所述方法還包括在接收所述作業已經失敗的通知之後，在把所述作業路由到診斷區域之前，檢查所述作業能夠且應當被重試。基於事務內部的操作的各方面，某些類型的事務可能不適於重試。例如，事務名稱可以用於識別該事務是可以恢復的還是不可以恢復的，並且這個信息可以用於決定是否把失敗的作業重新路由到診斷區域。理想地，所述方法還包括在把所述作業路由到診斷區域之後，接收所述作業再次失敗的進一步通知並捕獲診斷數據。如果作業在診斷區域處重試之後還失敗，則系統可以被配置成使得它自動捕獲具體的診斷數據，這些診斷數據將與可以獲得的關於該作業單元的任何其它信息(諸如，由該作業單元上所存在的任何跟蹤所收集的信息)一起被存儲。這為必須調查造成作業單元失敗的系統故障的原因和影響的管理員提供了儘可能多的信息。優選地，所述方法還包括在把所述作業路由到診斷區域之後，接收所述作業已經成功的進一步通知並相應地通知所述作業的源。如果在診斷區域中重試之後作業單元實際上成功了，則事務處理系統可以被配置成使得它將忽略原始的錯誤並基於該作業已經完成並提交來繼續。可以通知該作業的源作業已經成功而且系統可以繼續正常運行。這減少了所造成的錯誤管理的量並且提供了更健壯的事務處理系統，這種系統在作業單元失敗方面將產生較少的錯誤。
現在將參考附圖僅僅作為例子描述本發明的實施方式，其中圖I是事務處理系統的示意圖，
圖2是事務處理系統的進一步示意圖，其示出了作業單元的路由，圖3是操作事務處理系統的方法的流程圖，及圖4是系統中作業流的通信圖。
具體實施例方式圖I從邏輯的角度示出了事務處理系統的一個例子。該系統包括一個或多個生產區域10，在這個例子中是四個生產區域10，及一個或多個診斷區域12，在這個例子中是一個診斷區域12。提供了路由區域14，該路由區域14控制作業到生產區域10和診斷區域12的流動。雖然示出了單個路由區域14，但是有可能有多於一個路由區域14。路由程序20把作業分別路由到位於生產區域10和診斷區域12中的應用程式16和18。為了路由到相關的區域10或者12，用戶請求(也稱為事務或者作業單元)到達路由區域14。在圖I的事務處理系統中，生產區域10以最少的診斷功能或者沒有診斷功能地運行，而診斷區域12以最多的診斷功能或者全部的診斷功能地運行。對於特定的區域，諸如跟蹤的診斷功能必須或者由操作人員手動地啟用或者利用配置數據自動地啟用。當作業在對應的區域內執行時，這些功能提供了關於作業單元的信息的捕獲與記錄。儘管這些功能的主要優點是它們在發生錯誤的情況下提供大量信息，但主要的缺點是它們使區域內的處理變慢。圖I的圖是不同區域10和12的邏輯表示。實際上，共享硬體將提供不同區域10和12的處理和存儲需求。具體數量的CPU資源將被分配給不同的區域10和12，並且一般而言，將為生產區域10分配大部分的CPU資源，而只為診斷區域12分配少量的CPU資源。一般而言，生產區域10將運行以每秒鐘處理數千個用戶請求，而診斷區域12隻在需要診斷信息時才在規定的條件下使用。該系統被配置成具有一個或多個終端所有的區域14 (TOR)和多個克隆的應用所有區域10和12 (AOR)0大部分AOR都被配置成用於生產用途。一個或多個被配置成用於診斷用途。如圖2中所示，進入的請求22進入TOR 14，TOR 14把請求22路由到生產AOR
10。這可以動態地或者靜態地進行。作業單元22被路由到生產區域10中的應用程式16。請求22在AOR 10中運行，該AOR 10協調可能在其它區域或系統中運行的作業。這個作業可能是可以恢復的。
如果請求22失敗而且請求22是可以恢復的，請求22就退出。通知TOR 14失敗。通過重新路由到診斷AOR 12, TOR重試請求22,這可以動態地或者靜態地進行。請求22在診斷區域12中成功地運行或者失敗，並且通知TOR 14，然後TOR 14通知作業22的原始源。以這種方式，事務22首先被路由到生產區域10，而如果事務22由於任何原因失敗，則其被重新路由到診斷區域12。然後作業22在診斷區域12處被重試。重試可以基於例如事務名稱來配置，事務名稱還將識別它是可以恢復的事務還是不可以恢復的事務。因為不期望把太多請求重新路由到一個區域，所以重試還可以基於診斷系統10的異常終止代碼或者其它的診斷和/或可用性。作業單元22在診斷區域12中的重試將導致作業22成功或者作業22再次失敗。如果作業22成功，這被傳送迴路由區域14並且作業22以正常方式完成。如果作業22再次失敗，那麼現在就可以獲得診斷信息。重試還可以基於請求或事務22的其它特徵。還可能期望基於其它信息，諸如對於特定類型的問題是否已經捕獲到足夠的診斷。概述作業單元22的處理的流程圖在圖3中示出。第一步是路由程序20把作業22發送到生產區域10以執行作業22的步驟。下一步是作業22在生產區域10上運行的步驟。通知路由程序20作業22成功或者失敗。如果作業22失敗，就進行檢查，看作業22是否是以可以重試而且期望進行診斷的方式失敗的。重試可以基於諸如事務名稱或其它信息，諸如是否已經為特定類型的問題捕獲到足夠的診斷，來配置。如果答案是否定的，則該方法終止。在這個時候，生成傳統的錯誤。如果檢查步驟中對關於作業是否可以重試的問題的答案是肯定的，路由程序20就把作業22發送到診斷區域12去執行。下一步是作業22在診斷區域12上執行。然後，執行檢查以看作業是否失敗。如果作業沒有失敗，則該方法終止。在這個時候，原始的作業塊22已經成功執行了。這發生在診斷區域12中的事實並不重要，作業已經在系統中某個地方被執行就夠了。如果作業在診斷區域12上重試的時候再次失敗，就執行捕獲診斷的步驟，這是終止之前的最後一個處理步驟。由於作業單元22在診斷區域中被執行的事實，捕獲診斷步驟是除正在自動捕獲的任何診斷數據之外附加的。例如，為了獲得儘可能多的關於當前配置的數據，以幫助進行作業22在診斷區域12上最終失敗之後可能發生的任何隨後的錯誤分析，可以進行系統在當前狀態下的轉儲(dump)。對於系統將能夠重試的任何事務22，存在能訪問相同資源集合的備選區域12。該備選區域12被恆定地設置成「備用的」，除重新運行先前失敗的事務22之外不做任何工作。當事務22在這個區域12中帶跟蹤地重新運行時，有非常少的其它事務並行運行幹擾其行為，因而成功的機會可能更高。如果原始事務的失敗是由於壞數據或者有缺陷的程序邏輯，那麼重新運行的事務將再次失敗，並且在這種情況下，系統將捕獲好的診斷數據。圖4利用上述的作業單元22的路由說明了事務處理系統中的通信流。用戶將首先啟動作業22，作業22轉到路由程序20，然後路由程序20把該作業22發送到生產區域10。當作業22在生產區域10失敗時，路由程序20將把作業22發送到診斷區域12，以在診斷條件下執行作業22。作業22在診斷區域12中的成功或失敗被傳送回到路由程序20，然後路由程序20相應地通知用戶。以這種方式，提供了一種事務處理系統，其中存在很少或者沒有會使正在處理正常作業22的生產區域10變慢的診斷，但是，當事務22失敗時，通過在診斷區域12中重試作業22，可以對事務22使用診 斷，以使得如果作業的重試仍然失敗，可以立即獲得診斷數據。事務處理系統的這種配置提供了改進的對事務失敗的診斷、在無用戶或操作人員幹預的情況下的附加診斷的自動收集及問題診斷更快更便宜的可能性。如果作業22在重試的時候成功，那麼這就減少了所產生錯誤的量，而用戶不會意識到發生了任何重試。
權利要求
1.一種用於處理事務處理系統中的作業單元的方法，所述系統包括一個或多個生產區域和一個或多個診斷區域，其中所述生產區域運行最少的診斷功能或者不運行診斷功能，而所述診斷區域運行最多的診斷功能或者運行全部診斷功能，所述方法包括步驟 接收作業單元， 把所述作業路由到生產區域， 接收所述作業已經失敗的通知，及 把所述作業路由到診斷區域。
2.如權利要求I所述的方法，還包括 在接收所述作業已經失敗的通知之後，在把所述作業路由到診斷區域之前，檢查所述診斷區域可用。
3.如權利要求I或者2所述的方法,還包括 在接收所述作業已經失敗的通知之後，在把所述作業路由到診斷區域之前，檢查所述作業能夠且應當被重試。
4.如權利要求1、2或者3所述的方法,還包括 在把所述作業路由到診斷區域之後，接收所述作業再次失敗的進一步通知並捕獲診斷數據。
5.如前面任一項權利要求所述的方法，還包括 在把所述作業路由到診斷區域之後，接收所述作業已經成功的進一步通知並相應地通知所述作業的源。
6.一種用於處理作業單元的事務處理系統，包括一個或多個生產區域和一個或多個診斷區域，其中所述生產區域運行最少的診斷功能或者不運行診斷功能，而所述診斷區域運行最多的診斷功能或者運行全部診斷功能，所述系統被布置成 接收作業單元， 把所述作業路由到生產區域， 接收所述作業已經失敗的通知，及 把所述作業路由到診斷區域。
7.如權利要求6所述的系統，其中所述系統還被布置成在接收所述作業已經失敗的通知之後，在把所述作業路由到診斷區域之前，檢查所述診斷區域可用。
8.如權利要求6或者7所述的系統，其中所述系統還被布置成在接收所述作業已經失敗的通知之後，在把所述作業路由到診斷區域之前，檢查所述作業能夠且應當被重試。
9.如權利要求6、7或者8所述的系統，其中所述系統還被布置成在把所述作業路由到診斷區域之後，接收所述作業再次失敗的進一步通知並捕獲診斷數據。
10.如權利要求6至9中任何一項所述的系統，其中所述系統還被布置成在把所述作業路由到診斷區域之後，接收所述作業已經成功的進一步通知並相應地通知所述作業的源。
11.一種計算機可讀介質上的電腦程式產品，所述電腦程式產品用於處理事務處理系統中的作業單元，所述系統包括一個或多個生產區域和一個或多個診斷區域，其中所述生產區域運行最少的診斷功能或者不運行診斷功能，而所述診斷區域運行最多的診斷功能或者運行全部診斷功能，所述電腦程式產品包括用於執行以下動作的指令 接收作業單元， 把所述作業路由到生產區域， 接收所述作業已經失敗的通知，及 把所述作業路由到診斷區域。
12.如權利要求11所述的電腦程式產品，還包括用於執行以下動作的指令在接收所述作業已經失敗的通知之後，在把所述作業路由到診斷區域之前，檢查所述診斷區域可用。
13.如權利要求11或者12所述的電腦程式產品，還包括用於執行以下動作的指令在接收所述作業已經失敗的通知之後，在把所述作業路由到診斷區域之前，檢查所述作業能夠且應當被重試。
14.如權利要求11、12或者13所述的電腦程式產品，還包括用於執行以下動作的指令在把所述作業路由到診斷區域之後，接收所述作業再次失敗的進一步通知並捕獲診斷數據。
15.如權利要求11至14中任何一項所述的電腦程式產品，還包括用於執行以下動作的指令在把所述作業路由到診斷區域之後，接收所述作業已經成功的進一步通知並相應地通知所述作業的源。
全文摘要
本發明公開涉及事務處理系統。尤其是，公開了用於處理事務處理系統中的作業單元的方法，所述系統包括一個或多個生產區域和一個或多個診斷區域，其中所述生產區域運行最少的診斷功能或者不運行診斷功能，而所述診斷區域運行最多的診斷功能或者運行全部診斷功能。所述方法包括步驟接收作業單元，把所述作業路由到生產區域，接收所述作業已經失敗的通知，及把所述作業路由到診斷區域。
文檔編號G06F9/46GK102918507SQ201180024307
公開日2013年2月6日 申請日期2011年4月7日 優先權日2010年5月18日
發明者C·R·佩弗裡德, P·約翰森 申請人:國際商業機器公司