專利名稱：不間斷事務(wù)處理系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及不間斷事務(wù)處理系統(tǒng)。更詳細(xì)的講，涉及用于不間斷 事務(wù)系統(tǒng)構(gòu)筑的事務(wù)處理方法、處理系統(tǒng)及其控制程序。
背景技術(shù)：
在當(dāng)前的業(yè)務(wù)類系統(tǒng)中，由于服務(wù)器等的系統(tǒng)故障而暫時(shí)停止事 務(wù)處理成為一個(gè)很大的問題。為此，例如在專利文獻(xiàn)l中，公開了診 斷并自我修復(fù)服務(wù)器中心(服務(wù)器群的組)中的服務(wù)器故障的方法以 及系統(tǒng)。
專利文獻(xiàn)1:特開2004 - 110790號(hào)7>報(bào)
從系統(tǒng)的利用者來看，即使發(fā)生系統(tǒng)故障，但如果在相對(duì)于正常 的時(shí)候沒有改變的時(shí)間內(nèi)(大多系統(tǒng)中是2、 3秒)完成事務(wù)處理則 沒有問題，但是在一般的系統(tǒng)中，難以使停止時(shí)間收斂在上述的時(shí)間 以內(nèi)。
當(dāng)前的業(yè)務(wù)系統(tǒng)的抗故障機(jī)構(gòu)以故障檢測(cè)和移交處理為基本。 即，釆用如果檢測(cè)出故障則立即進(jìn)行切換的方式。然而，在故障檢測(cè) 方面一般需要10秒~幾分鐘。這是因?yàn)楣收蠙z測(cè)經(jīng)由通信，以外部 計(jì)算機(jī)與對(duì)象服務(wù)器的消息交換是否拖延來進(jìn)行判斷。
然而，即使對(duì)象服務(wù)器正常動(dòng)作，但有時(shí)由于負(fù)栽暫時(shí)較高，消 息交換發(fā)生拖延，因此在某個(gè)時(shí)間內(nèi)試行若干次消息交換，這樣做也 不能正常進(jìn)行消息交換的情況下，判斷為在對(duì)象服務(wù)器中發(fā)生了故 障。如果把該應(yīng)答等待時(shí)間或者試行次數(shù)設(shè)定為過小，則盡管對(duì)象服 務(wù)器正常進(jìn)行動(dòng)作，但故障檢測(cè)機(jī)構(gòu)也判斷為發(fā)生故障，開始在備用 服務(wù)器中的移交處理。因此，在生存確認(rèn)方面，至少設(shè)置10秒左右 的時(shí)間。因此，不能在從利用者來看不知道系統(tǒng)故障的程度的時(shí)間內(nèi)進(jìn)行 故障檢測(cè)和移交。這一點(diǎn)在故障檢測(cè)中是本質(zhì)性的。為了進(jìn)一步縮短 用于生存確認(rèn)的時(shí)間，需要準(zhǔn)備生存確認(rèn)的消息處理專用的網(wǎng)絡(luò)，進(jìn) 而，在對(duì)象服務(wù)器中準(zhǔn)備了生存確認(rèn)專用的處理器的基礎(chǔ)上，需要用 于確認(rèn)操作系統(tǒng)或者其上的處理是否正常進(jìn)行動(dòng)作的機(jī)構(gòu)。然而這需
要變更硬件和操作系統(tǒng)，當(dāng)前狀況下的開放式平臺(tái)(open flatform ) 的環(huán)境不能響應(yīng)要求。

發(fā)明內(nèi)容
從而，本發(fā)明是為解決上述課題而完成的，其目的在于提供不等 待系統(tǒng)的故障檢測(cè)，在一定時(shí)間沒有應(yīng)答的情況下，能夠向備用系統(tǒng) 再次發(fā)送處理的新的事務(wù)處理方法等。
在本發(fā)明中，主要設(shè)想下面那樣的條件。
由一個(gè)數(shù)據(jù)管理機(jī)構(gòu)和更新該機(jī)構(gòu)中的數(shù)據(jù)的一個(gè)以上的服務(wù) 器構(gòu)成的組(以下，把該組稱為服務(wù)器中心(server farm))存在(2F + 1)組(F是自然數(shù))。關(guān)于該服務(wù)器中心的組存在發(fā)行事務(wù)請(qǐng)求的 客戶端，各服務(wù)器中心之間、客戶端與服務(wù)器中心之間，經(jīng)由具有多 條數(shù)據(jù)發(fā)送路徑的冗余化(多重化)了的網(wǎng)絡(luò)被連接。能夠從一個(gè)客 戶端投入多次同 一事務(wù)的請(qǐng)求，客戶端在等待一定時(shí)間也沒有得到來 自一個(gè)服務(wù)器中心的應(yīng)答的情況下，向其它的服務(wù)器中心發(fā)送同一個(gè) 事務(wù)的請(qǐng)求。另外，雖然任意的網(wǎng)絡(luò)以及服務(wù)器中心隨時(shí)有可能成為 功能不全，但是由于故障而陷入功能不全的最多只有F組的服務(wù)器中 心。
圖1表示了本發(fā)明設(shè)想的系統(tǒng)基本形式(相當(dāng)于F = 1的情況)。 如在這里所示，在各服務(wù)器中心1 3中，分別存在多個(gè)應(yīng)用服 務(wù)器(lc~3c)、各服務(wù)器中心中的一個(gè)數(shù)據(jù)庫(DBla、 2a、 3a )和 管理其DB的DB服務(wù)器(lb、 2b、 3b)。請(qǐng)求事務(wù)的客戶端4、 5 經(jīng)由各服務(wù)器中心內(nèi)的應(yīng)用服務(wù)器和DB服務(wù)器，訪問事務(wù)所需要的 數(shù)據(jù)庫。圖2表示了本發(fā)明設(shè)想的最小的結(jié)構(gòu)。圖中的仲裁器(arbiter) 8是服務(wù)器中心的特殊形式，是僅為了使其它的服務(wù)器中心正常工作 的不進(jìn)行事務(wù)處理也不具有DB的服務(wù)器中心。例如，在F-l的情 況下，雖然在本發(fā)明中需要3個(gè)服務(wù)器中心，但不需要把DBMS(數(shù) 據(jù)庫管理系統(tǒng))三重化的情況也很多。而本發(fā)明由于以基于多數(shù)決定 的分散合意協(xié)議為基礎(chǔ)，因此需要即使在二重化的情況下，也進(jìn)行針 對(duì)多數(shù)決定的投票的服務(wù)器。進(jìn)行該動(dòng)作的是仲裁器8。
以下，以(2F + 1)組(奇數(shù)組)為基本說明服務(wù)器中心，而通 過這樣在結(jié)構(gòu)中包括仲裁器8，在2F組(偶數(shù)組)的服務(wù)器中心的系 統(tǒng)中也能夠應(yīng)對(duì)。
本發(fā)明的課題在這樣的條件下，保證下面的3點(diǎn)。
<課題1>即使在多次重復(fù)執(zhí)行同一個(gè)事務(wù)的情況下，最多有一 個(gè)執(zhí)行在提交中成功(完成提交)。
<課題2 >根據(jù)最新的數(shù)據(jù)執(zhí)行提交完成了的事務(wù)。
<課題3>即使某個(gè)服務(wù)器中心由于故障而停止，也不會(huì)長時(shí)間 停止這些事務(wù)處理而能繼續(xù)進(jìn)行。
為了解決這樣的課題，在本發(fā)明的第1實(shí)施形態(tài)中提供以下的處 理方法。
(l)在事務(wù)開始處理中，處理下述步驟的方法。 步驟1:在事務(wù)開始處理中，參照對(duì)象事務(wù)的ID，確認(rèn)是否已 經(jīng)正在執(zhí)行同一個(gè)ID的事務(wù)，或者提交已經(jīng)完成，如果是正在執(zhí)行 或者提交已經(jīng)完成，則回退(取消)對(duì)象事務(wù)。
步驟2:進(jìn)而，在事務(wù)開始處理中，自身服務(wù)器中心確認(rèn)是否保 持著沒有用盡有效期間的處理權(quán)限Token (帶時(shí)間限制的Token ), 如果沒有保持它，則使用「在2F + 1臺(tái)的服務(wù)器群中的利用了處理權(quán) 限Token的排斥控制技術(shù)」，進(jìn)行處理權(quán)限Token的取得處理，等 待其取得完成。
步驟3:進(jìn)而，在進(jìn)行了上述的處理權(quán)限Token的取得處理的情 況下，在該處理的同時(shí)，或者緊接在其以后，使用r在2F + l臺(tái)的月良務(wù)器群中的取得數(shù)據(jù)匹配的技術(shù)」，自身服務(wù)器中心在系統(tǒng)內(nèi)的所有 的服務(wù)器中心之間保持最新的數(shù)據(jù)。
這里，「在2F + 1臺(tái)的服務(wù)器群中的利用了處理權(quán)限Token的 排斥控制技術(shù)」和r在2F + 1臺(tái)的服務(wù)器群中的取得數(shù)據(jù)匹配的技術(shù)J 如后所述，使用公知技術(shù)。
另外，是除去(1)的處理以外，還處理(2)的步驟的方法。 (2)在事務(wù)的提交處理中，執(zhí)行下述的處理流程。
步驟l:在提交處理中，使用「2F + 1臺(tái)的服務(wù)器群中的更新數(shù) 據(jù)的復(fù)制技術(shù)」，向所有的服務(wù)器中心傳送對(duì)象事務(wù)的事務(wù)ID、該事 務(wù)更新了的數(shù)據(jù)、向該事務(wù)的請(qǐng)求源返送的處理結(jié)果，確認(rèn)至少對(duì)于 F + l臺(tái)的服務(wù)器的拷貝。
步驟2:進(jìn)而，在步驟l成功了的情況下，使用r在2F+l臺(tái)的 服務(wù)器群中的基于分散合意的能否提交的判斷技術(shù)」，向其它所有的 服務(wù)器發(fā)送提交請(qǐng)求消息，如果至少接收到來自F + l臺(tái)服務(wù)器的提 交合意，則當(dāng)作提交成功。
步驟3:進(jìn)而，使所有的服務(wù)器中心知道提交被確定了。
這里，「在2F + 1臺(tái)的服務(wù)器群中的更新數(shù)據(jù)的復(fù)制技術(shù)J和 r在2F + 1臺(tái)的服務(wù)器群中的基于分散合意的能否提交的判斷技術(shù)J 如后所述，使用公知技術(shù)。
(1)和(2)表示本發(fā)明的主要處理，進(jìn)而作為添加的處理，包 括以下的方法。
(3 )在處理權(quán)限Token取得處理中接收到提交請(qǐng)求消息的情況 下，直到處理權(quán)限Token取得處理完成為止，不進(jìn)行針對(duì)提交請(qǐng)求消 息的應(yīng)答，或者，應(yīng)答提交請(qǐng)求消息的再次發(fā)送委托的處理。
(4) 在向其它的服務(wù)器中心發(fā)送提交請(qǐng)求消息，接收其應(yīng)答而 確定提交為止的期間中，在接收到處理權(quán)限Token取得消息的情況 下，直到提交確定為止，不進(jìn)行針對(duì)處理權(quán)限Token取得消息的應(yīng)答， 或者，應(yīng)答處理權(quán)限Token取得消息的再次發(fā)送委托的處理。
(5) 在處理權(quán)限Token取得完成之前，從其它服務(wù)器取得未確定的事務(wù)的日志，使事務(wù)日志的狀態(tài)同步的處理。(6 )在處理權(quán)限Token取得消息的接收處理以及其應(yīng)答消息的 接收處理中，在消息內(nèi)包括提交不明確的事務(wù)信息的情況下，參照該 信息，在該事務(wù)的提交或者回退已經(jīng)確定了的情況下，返送其結(jié)果， 在還沒有確定的情況下，根據(jù)(2)的方法，進(jìn)行提交確定的處理。(7)作為事務(wù)的提交請(qǐng)求消息的接收處理，判斷其消息的發(fā)送 源以外是否保持著有效的處理權(quán)限Token,如果是保持著，則對(duì)于提 交請(qǐng)求應(yīng)答拒絕，如果沒有保持，則對(duì)于提交請(qǐng)求應(yīng)答承認(rèn)的提交請(qǐng) 求承認(rèn)處理。(8 )根據(jù)事務(wù)處理的應(yīng)答時(shí)間的估計(jì)值計(jì)算發(fā)送事務(wù)處理請(qǐng)求 的客戶端的事務(wù)的再次發(fā)送時(shí)間和用r在2F + l臺(tái)的服務(wù)器群中的利 用了處理權(quán)限Token的排斥控制技術(shù)」設(shè)定的Token的有效期間， 設(shè)定到客戶端一側(cè)的再次發(fā)送.Token有效期間設(shè)定處理。以上作為事務(wù)處理方法說明了本發(fā)明的解決方法的一個(gè)實(shí)施形 態(tài)，而作為其它的實(shí)施形態(tài)，能夠通過具有同樣功能的處理裝置、處 理機(jī)構(gòu)(處理系統(tǒng))以及控制它們的計(jì)算機(jī)程序?qū)崿F(xiàn)。在本發(fā)明中提出了，不等待故障檢測(cè)，在一定時(shí)間內(nèi)沒有應(yīng)答的 情況下，從客戶端向備用的服務(wù)器中心再次發(fā)送處理的系統(tǒng)。即，本 發(fā)明的事務(wù)處理具備把使用了處理權(quán)限Token的排斥控制和數(shù)據(jù)匹 配組合起來的事務(wù)開始處理、把基于分散合意的能否提交判斷和更新 數(shù)據(jù)的復(fù)制組合起來的提交處理。根據(jù)該處理，能夠比現(xiàn)有技術(shù)更縮 短由應(yīng)用服務(wù)器、DBMS (數(shù)據(jù)庫管理系統(tǒng))、網(wǎng)絡(luò)中發(fā)生的故障引 起的服務(wù)停止時(shí)間，能夠構(gòu)筑客戶端不必識(shí)別故障發(fā)生，就可以繼續(xù) 服務(wù)的系統(tǒng)。


圖l表示事務(wù)處理系統(tǒng)的基本形式。 圖2表示事務(wù)處理系統(tǒng)的最小結(jié)構(gòu)。 圖3表示F-1時(shí)的Paxos提交的結(jié)構(gòu)例。圖4表示本發(fā)明一個(gè)實(shí)施形態(tài)的系統(tǒng)結(jié)構(gòu)和提案機(jī)構(gòu)的位置的例子。
圖5表示本發(fā)明一個(gè)實(shí)施形態(tài)的事務(wù)處理系統(tǒng)。
圖6表示最初和備用的服務(wù)器中心的消息的收發(fā)處理單元。
圖7表示Token請(qǐng)求發(fā)送單元61的處理流程。
圖8表示Token應(yīng)答接收單元62的處理流程。
圖9表示Token請(qǐng)求處理單元63的處理流程。
圖10表示Token請(qǐng)求處理63的處理流程(繼續(xù))。
圖11表示提交請(qǐng)求發(fā)送單元64的處理流程。
圖12表示提交請(qǐng)求應(yīng)答接收單元65的處理流程。
圖13表示提交請(qǐng)求處理單元66的處理流程。
(附圖標(biāo)記說明) 1、 2、 3服務(wù)器中心 la、 2a、 3a DB lb、 2b、 3b DB服務(wù)器 lc、 2c、 3c應(yīng)用服務(wù)器 4、 5客戶端 8仲裁器 40服務(wù)器中心 41應(yīng)用服務(wù)器 42 DB服務(wù)器 45事務(wù)前端機(jī)構(gòu) 46事務(wù)后端機(jī)構(gòu) 46b提案機(jī)構(gòu) 50事務(wù)處理系統(tǒng) 51事務(wù)開始處理機(jī)構(gòu) 51a控制單元 51b事務(wù)重復(fù)檢測(cè)單元 51c Token排斥控制單元51d數(shù)據(jù)匹配處理單元 52提交處理機(jī)構(gòu) 52b數(shù)據(jù)復(fù)制處理單元 52c提交確定處理單元 52d提交發(fā)送單元 53有效期間設(shè)定機(jī)構(gòu) 53a控制單元
53b事務(wù)再次發(fā)送時(shí)間設(shè)定單元 53c Token有效期間設(shè)定單元 53d客戶端通信單元 60a最初服務(wù)器中心 60b備用服務(wù)器中心
61 Token請(qǐng)求發(fā)送單元
62 Token應(yīng)答接收單元
63 Token請(qǐng)求處理單元 64提交請(qǐng)求發(fā)送單元
65提交請(qǐng)求應(yīng)答接收單元
66提交請(qǐng)求處理單元
67a處理權(quán)限Token取得請(qǐng)求消息
67b處理權(quán)限Token取得請(qǐng)求應(yīng)答消息
68a提交請(qǐng)求消息
68b提交請(qǐng)求應(yīng)答消息
70處理權(quán)限Token取得請(qǐng)求消息發(fā)送處理
80對(duì)于處理權(quán)限Token取得請(qǐng)求的應(yīng)答消息接收處理
90處理權(quán)限Token取得請(qǐng)求消息接收處理
IIO提交請(qǐng)求消息發(fā)送處理
120對(duì)提交請(qǐng)求的應(yīng)答消息接收處理
130提交請(qǐng)求消息接收處理
具體實(shí)施例方式
在本發(fā)明中，提供同時(shí)解決已經(jīng)敘述過的3個(gè)課題，保證必須在 一個(gè)服務(wù)器中心中進(jìn)行某個(gè)事務(wù)的提交，進(jìn)而，保證提交成功的事務(wù) 始終對(duì)于最新的數(shù)據(jù)進(jìn)行的事務(wù)處理。本發(fā)明的基本原理如下。
<課題1的解決技術(shù)>
為了防止在多個(gè)服務(wù)器中心中多重處理某個(gè)事務(wù)，使用在下述的 文獻(xiàn)1 ~ 3中提出的基于Mutual Exclusion技術(shù)的r處理權(quán)限Token J。
1) Suzuki, I, Kasami, T, A distributed mutual exclusion algorithm, ACM T ransactions on Computer Systems (TOCS), v.3 n.4, p,344—349, Nov. 1985.
2) Nishio, S., Li, K.F., Manning, E.G., A resilient mutual exclusion algorit hm for computer networks, IEEE Transactions on Parallel and Distributed S ystems， v.l n.3 , p.344-355, July 1990.
3) Banerjee, S.; Chrysanthis, P,K., A new Token passing distributed mutua 1 exclusion algorithm, Proceedings of the 16th International Conference on Distributed Computing Systems, 1996.， p.717-724, May 1996.
Mutual Exclusion技術(shù)是在多個(gè)服務(wù)器群(服務(wù)器中心)中，使 得只有一個(gè)服務(wù)器能夠保持Token的通用化了的技術(shù)。在本發(fā)明中， 使用該技術(shù)，在某個(gè)時(shí)刻具有有效的處理權(quán)限Token的服務(wù)器中心在 2F + 1個(gè)服務(wù)器中心內(nèi)僅存在1個(gè)。在某個(gè)服務(wù)器中心的提交處理時(shí)， 在不具有有效處理權(quán)限Token的情況下，其服務(wù)器中心嘗試再次取得 處理權(quán)限Token,在不能取得的情況下，回退(rollback)事務(wù)。在 處理權(quán)限Token中設(shè)定有效期限。如果該有效期限用盡，則其處理權(quán) 限Token成為無效，其它的服務(wù)器中心能夠重新取得處理權(quán)限Token 。 在典型的情況下，為了縮短由故障引起的系統(tǒng)的停止時(shí)間，將處理權(quán) 限Token的有效期間設(shè)定為1秒左右。但也能延長處理權(quán)限Token 的有效期間。
<課題2的解決技術(shù)>
在本發(fā)明中，使用在2F + 1臺(tái)的服務(wù)器群內(nèi)的F臺(tái)以上的服務(wù) 器中拷貝數(shù)據(jù)的(由于自身服務(wù)器中心也具有數(shù)據(jù)，因此在整體上成為過半數(shù)、即F+l臺(tái)以上的服務(wù)器中心具有數(shù)據(jù))數(shù)據(jù)復(fù)制技術(shù)， 以及把2F + 1臺(tái)的服務(wù)器群內(nèi)的F + l臺(tái)以上的服務(wù)器群具有的數(shù)據(jù) 作為2F+1臺(tái)的服務(wù)器群中的合意完畢的數(shù)據(jù)來處理的數(shù)據(jù)匹配技術(shù)。這些技術(shù)是已經(jīng)公知的通用化的技術(shù)(文獻(xiàn)4、 5)。4) 丄 Gray and A. Reuter, Transaction Processing Concepts and Technique s, Mogem KEiufiimnn5) M. Wiesmann, F. Pedone, A. Schiper， B. Kemme, and G, Alonso Unde rstanding replication in databases and distributed systems. In Proceedings of20th International Conference on Distributed Computing Systems 〔ICDCS' 2000〕， p.264—274， April 2000.<課題3的解決技術(shù)>在事務(wù)的提交處理中，較出名的有2相提交協(xié)議(Two-Phase Commit Protocol)，而其作為Blocking協(xié)i義也4皮熟知。所謂Blocking 協(xié)議是如果進(jìn)行事務(wù)的提交處理的協(xié)調(diào)器(coordinator)由于故障而 停止，則其事務(wù)的提交成為未確定，在取得該協(xié)調(diào)器的決定結(jié)果之前 不能確定事務(wù)的提交處理的協(xié)議。從而，在該協(xié)議中，不能解決課題 3。 J. Gray等作為解決該問題的技術(shù)提出了在提交處理中應(yīng)用了 L. Lamport等提出的采取2F + 1臺(tái)的服務(wù)器群中的合意的Paxos共識(shí)協(xié) 議(文獻(xiàn)6 )的Paxos提交協(xié)議(文獻(xiàn)7 )。該協(xié)議是如果2F + 1臺(tái) 的服務(wù)器群內(nèi)的F + l臺(tái)以上的服務(wù)器正常工作，則能夠無阻塞地完 成提交處理的協(xié)議。在本發(fā)明中，作為解決課題3的提交處理技術(shù)，利用Paxos提交。6) L, Lamport, Generalized Consensus and Paxos, Microsoft Research Technical R印ort MSR-TR-2005-337) J. Gray and L. Lamport, Consensus on Transetction Commit, MSR-TR-2 003-96)<課題1~3整體的解決>課題l、 2、 3分別存在解決的技術(shù)。然而，在本發(fā)明中，必須同 時(shí)解決這些全部的3個(gè)課題。即使單獨(dú)利用課題1~3的各個(gè)解決技 術(shù)，也不能同時(shí)解決全部的課題1~3。例如，在解決課題1的MutualExclusion中，能夠防止同一事務(wù)的多重處理，但是不能保證進(jìn)行了 提交的事務(wù)處理對(duì)于2F+1臺(tái)服務(wù)器群中的最新的數(shù)據(jù)集合進(jìn)行。在 解決課題2的數(shù)據(jù)復(fù)制技術(shù)以及數(shù)據(jù)匹配技術(shù)中，不能防止同一事務(wù) 的多重處理。在解決課題3的Paxos提交中，既不能解決同一事務(wù)的 多重處理，也不能保證對(duì)于2F + 1臺(tái)的服務(wù)器群中的最新的數(shù)據(jù)集合 進(jìn)行提交處理。從而，為了同時(shí)解決全部的課題1~3，需要把解決各 個(gè)課題的技術(shù)適當(dāng)?shù)厝诤?，重新建立算法。在本發(fā)明的事務(wù)處理機(jī)構(gòu)中，在事務(wù)的開始時(shí)，進(jìn)行用于防止事 務(wù)的多重處理的處理權(quán)限Token的確認(rèn)處理。在具有處理權(quán)限Token 的情況下，事務(wù)的開始處理結(jié)束。不具有處理權(quán)限Token的服務(wù)器中 心進(jìn)行處理權(quán)限Token取得處理和數(shù)據(jù)匹配處理這兩種處理。處理權(quán)限Token取得處理按照Mutual Exclusion中表示的方法 進(jìn)行。在失敗的情況(其它服務(wù)器中心已經(jīng)取得的情況)下，使事務(wù) 的開始處理失敗。在Mutual Exclusion中，對(duì)于處理權(quán)限Token取得 請(qǐng)求，如果可以得到來自F + 1個(gè)服務(wù)器中心的合意，則能取得Token。從而，2F + 1個(gè)服務(wù)器中心中能夠取得處理權(quán)限Token的服務(wù)器 中心必定只是一個(gè)。另外，即使最多F個(gè)服務(wù)器中心(例如服務(wù)器中 心中的DB服務(wù)器)停止，也能夠進(jìn)行處理權(quán)限Token取得。提供處 理權(quán)限Token的單位典型的是應(yīng)用單位，而嚴(yán)密地講，是對(duì)于這樣的 數(shù)據(jù)集合提供，即，作為某個(gè)事務(wù)的集合所訪問的數(shù)據(jù)集合，該事務(wù) 集合以外的事務(wù)不進(jìn)行訪問，而且該事務(wù)集合內(nèi)的任意的事務(wù)對(duì)該數(shù) 據(jù)集合以外的數(shù)據(jù)不進(jìn)行訪問的數(shù)據(jù)集合。接著為了對(duì)最新的數(shù)據(jù)進(jìn)行事務(wù)，在處理權(quán)限Token取得處理 時(shí)驗(yàn)證取得權(quán)限的服務(wù)器中心是否具有最新的數(shù)據(jù)，在不具有的情況 下，進(jìn)行從其它的服務(wù)器中心取得表示數(shù)據(jù)差分的事務(wù)日志的處理。 在本發(fā)明中，如果能夠?qū)τ贔 + l個(gè)服務(wù)器中心拷貝事務(wù)日志，則能 夠成功提交。從而，在2F + 1個(gè)服務(wù)器中心內(nèi)的F + l個(gè)服務(wù)器中心具有的事務(wù)日志的集合中必定存在最新的事務(wù)日志。這里，通過在事 務(wù)日志上提供連續(xù)號(hào)碼LSN (日志系列號(hào))，能夠把握取得了處理權(quán)限Token服務(wù)器中心不具有的事務(wù)曰志，能夠從服務(wù)器中心群搜索和 取得。在事務(wù)的提交處理中，進(jìn)行數(shù)據(jù)復(fù)制處理和提交確定處理。 首先，在數(shù)據(jù)復(fù)制處理中，進(jìn)行事務(wù)日志的拷貝，使得F + 1個(gè)以上的服務(wù)器中心具有事務(wù)日志。向生存的所有服務(wù)器中心傳送事務(wù)曰志，等待接收來自F個(gè)服務(wù)器中心的確認(rèn)消息。接著，提交的確認(rèn)處理根據(jù)Paxos提交進(jìn)行。進(jìn)行提交處理的服務(wù)器中心向生存的其它所有服務(wù)器中心發(fā)送r Prepare J消息。接收到該消息的各服務(wù)器中心在判斷為其發(fā)送源服務(wù)器中心以 外具有處理權(quán)限Token的情況下，作為r Abort」，沒有的情況下作 為r prepared J ,把決定結(jié)果發(fā)送到自己的稱為接受器(acceptor)的所有模塊中。這里，所謂接受器是僅具有對(duì)于某個(gè)服務(wù)器中心的提 交的決定結(jié)果的服務(wù)器，在每一個(gè)服務(wù)器中心中準(zhǔn)備2F+1個(gè)接受器。 接收到服務(wù)器中心的決定結(jié)果的接受器把該結(jié)果發(fā)送到正在進(jìn)行提 交處理的服務(wù)器中心。該服務(wù)器中心如果從某個(gè)服務(wù)器中心的接受器 中的F + l個(gè)以上的接受器接收到了決定結(jié)果，則就作為該服務(wù)器中 心的決定結(jié)果來處理。圖3表示本發(fā)明情況下F-l中的Paxos提交的結(jié)構(gòu)例。其中， 圖3中省略了從接受器向提交處理執(zhí)行^f莫塊的箭頭。這里，位于一個(gè)服務(wù)器中心中的各模塊(31a、 31b、 32a、 33b) 以及接收器(31c、 31d、 31e、 32c、 32d、 32e、 33c、 33d、 33e )既可 以配置在相同的服務(wù)器裝置中，也可以配置在不同的服務(wù)器裝置中。這里，分別說明了處理權(quán)限Token取得、數(shù)據(jù)匹配化、數(shù)據(jù)復(fù) 制、提交確定，實(shí)際上，由于在各個(gè)處理中進(jìn)行消息交換，因此消息 數(shù)增多而有可能使性能降低。但是，如果考慮到在事務(wù)開始處理中， 進(jìn)行處理權(quán)限Token取得和數(shù)據(jù)匹配，在提交處理中進(jìn)行數(shù)據(jù)復(fù)制和 提交確定，這些處理全部以取得來自2F + 1個(gè)服務(wù)器中心之間的F + 1個(gè)服務(wù)器中心的合意的所謂分散合意協(xié)議為基礎(chǔ)，則可以把用于事 務(wù)開始處理的處理權(quán)限Token取得處理和數(shù)據(jù)匹配的發(fā)送消息和接收消息匯總為一個(gè)消息，并且，把提交處理的數(shù)據(jù)復(fù)制和提交確定的 發(fā)送消息和接收消息也匯總為 一個(gè)消息，能夠防止由消息數(shù)增加引起 的性能下降。其中，匯總這種消息的動(dòng)作是通常進(jìn)行的動(dòng)作。該一系列的處理如果只是簡單地結(jié)合對(duì)于課題1~3的技術(shù)，則 不能起到作用。問題是某個(gè)服務(wù)器中心開始事務(wù)，在其進(jìn)行提交處理 之前用盡處理權(quán)限Token的有效期限的情況。這種情況下，其它的服 務(wù)器中心能夠取得處理權(quán)限Token。現(xiàn)在設(shè)服務(wù)器中心1具有處理權(quán)限Token,開始了事務(wù)A的提 交處理，而在事務(wù)A的提交處理結(jié)束之前用盡了處理權(quán)限Token的 有效期限。這種情況下，其它的服務(wù)器中心2能夠取得處理權(quán)限 Token,執(zhí)行新的事務(wù)B，能夠開始提交處理。這里，如果事務(wù)A和 B成功提交，則數(shù)據(jù)的匹配性變紊亂。由于事務(wù)A更新的數(shù)據(jù)的提交沒有確定，因此沒有反映到服務(wù) 器中心2中。從而，事務(wù)B對(duì)于進(jìn)行事務(wù)A之前的數(shù)據(jù)集合進(jìn)行。這 里，如果事務(wù)B進(jìn)行提交，緊接在其后事務(wù)A的提交結(jié)束，則有可能 丟失事務(wù)B的結(jié)果。為了防止這一點(diǎn)，在服務(wù)器中心2取得處理權(quán)限 Token的時(shí)刻，需要保證服務(wù)器中心1中正在處理的事務(wù)是確定的， 或者回退在服務(wù)器中心1中正在處理的事務(wù)。在本發(fā)明中，把對(duì)于課題1~3的各個(gè)解決技術(shù)結(jié)合起來，使得 保證以上的內(nèi)容。在本發(fā)明中，客戶端等待來自服務(wù)器的應(yīng)答結(jié)果的暫停時(shí)間和處 理權(quán)限Token的有效期限的設(shè)定是重要的。當(dāng)客戶端向備用的服務(wù)器 中心再次發(fā)送了事務(wù)處理請(qǐng)求時(shí)，已經(jīng)用盡了最初(primary)的服 務(wù)器中心的處理權(quán)限Token的有效期限的情形下由于立即進(jìn)行備用 的處理權(quán)限Token取得，因此效率良好。反之，在處理權(quán)限Token 的有效期限與直到客戶端再次發(fā)送為止的暫停時(shí)間相比過長的情況 下，備用的服務(wù)器中心中的處理權(quán)限Token取得不成功，客戶端向下 一個(gè)備用的服務(wù)器中心再次發(fā)送。這種情況下，在用盡了處理權(quán)限 Token的有效期限的瞬間，多個(gè)服務(wù)器中心同時(shí)想要取得處理權(quán)限Token,成為相互竟?fàn)庩P(guān)系，其結(jié)果，有可能哪一個(gè)服務(wù)器中心都不 能取得處理權(quán)限Token。直到客戶端的再次發(fā)送為止的暫停時(shí)間和處 理權(quán)限Token的有效期限考慮到這些問題，需要進(jìn)一步考慮事務(wù)的平 均處理時(shí)間、最大等待時(shí)間等來決定。 <就系統(tǒng)結(jié)構(gòu)的提案機(jī)構(gòu)的位置>圖4表示系統(tǒng)整體和本發(fā)明提出的機(jī)構(gòu)的一個(gè)例子。這里，表示 提案機(jī)構(gòu)46b處于服務(wù)器中心40中的DB服務(wù)器42內(nèi)的情況。然而， 提案機(jī)構(gòu)46b的位置不限于這種情況。本發(fā)明的事務(wù)處理機(jī)構(gòu)由應(yīng)用服務(wù)器41內(nèi)的事務(wù)前端機(jī)構(gòu)45 (以下，記述為事務(wù)Fr機(jī)構(gòu))和位于DB服務(wù)器42內(nèi)的事務(wù)后端機(jī) 構(gòu)46(以下，記述為事務(wù)Bk機(jī)構(gòu))構(gòu)成。事務(wù)Fr機(jī)構(gòu)在每一個(gè)事務(wù)中存儲(chǔ)業(yè)務(wù)邏輯生成的事務(wù)日志，用 事務(wù)Fr機(jī)構(gòu)的提交處理，向事務(wù)Bk機(jī)構(gòu)傳送存儲(chǔ)的事務(wù)日志。這里， 調(diào)用本發(fā)明的提案機(jī)構(gòu)46b，決定提交成功.失敗。接著，事務(wù)Bk機(jī) 構(gòu)如果提交成功，則使用事務(wù)日志經(jīng)由DBMS47更新DB43。接著， 向事務(wù)Fr機(jī)構(gòu)返送提交結(jié)果，應(yīng)用的提交處理結(jié)束。這里，在事務(wù) Fr機(jī)構(gòu)與事務(wù)Bk機(jī)構(gòu)之間不需要是2相提交。在事務(wù)Bk機(jī)構(gòu)中，當(dāng)在提案機(jī)構(gòu)46b決定提交成功以后，更新 DB43時(shí)，在DB服務(wù)器42中發(fā)生故障，更新失敗了的情況下，其服 務(wù)器中心功能停止，應(yīng)用的提交處理成為不完全的狀態(tài)(提交成功.失 敗不明確)，而根據(jù)提案機(jī)構(gòu)46b，事務(wù)日志向其它的服務(wù)器中心傳 送，在其服務(wù)器中心中進(jìn)行對(duì)DB43的更新。從而，客戶端只要再次 發(fā)送事務(wù)處理請(qǐng)求即可。這里，該事務(wù)日志與數(shù)據(jù)更新的歷史一起， 還保持向客戶端返送的事務(wù)處理結(jié)果，當(dāng)客戶端再次發(fā)送了事務(wù)處理 請(qǐng)求時(shí)，如果該事務(wù)已經(jīng)提交成功，則需要進(jìn)行從該事務(wù)日志取得處 理結(jié)果，返送該結(jié)果的處理。另外，在事務(wù)日志中包括事務(wù)的處理結(jié)果的機(jī)構(gòu)、以及來自客戶 端的事務(wù)處理請(qǐng)求再次發(fā)送時(shí)從事務(wù)日志取出并返送事務(wù)處理結(jié)果 的機(jī)構(gòu)由于不是本發(fā)明的主題因此省略說明。以下，研究本發(fā)明的替代方法。 <基于故障檢測(cè)的方法>
當(dāng)前最主流的方法是進(jìn)行故障檢測(cè)，進(jìn)行移交處理這樣的方法。
如前面敘述的那樣，該方法由于在故障檢測(cè)中至少需要10秒以上，
因此不能從客戶端隱蔽故障。 <基于多重處理的方法>
這是在多個(gè)服務(wù)器中進(jìn)行相同的處理，按照多數(shù)決定對(duì)其結(jié)果進(jìn) 行比較，把同意數(shù)多的結(jié)果作為整體結(jié)果的方法。該方法在航空機(jī)等 要求可靠性非常高的系統(tǒng)中使用。然而，如果把該方法導(dǎo)入到事務(wù)處 理系統(tǒng)中，則如下所述，在性能上將產(chǎn)生很大的問題。
在該方式中，在相互依賴的多個(gè)事務(wù)處理請(qǐng)求幾乎同時(shí)到達(dá)的情 況下，如果沒有在所有的服務(wù)器中以相同的順序進(jìn)行處理，則所有的
數(shù)據(jù)管理機(jī)構(gòu)所具有的數(shù)據(jù)不相同。例如，設(shè)現(xiàn)在有2個(gè)事務(wù)處理請(qǐng) 求A和B。 A、 B的處理分別是「如果數(shù)據(jù)X是0則使X成為1 ，如 果是0以外則不進(jìn)行任何處理」、r如果數(shù)據(jù)X是l則使X成為10， 如果是l以外則不進(jìn)行任何處理J 。這里，考慮在服務(wù)器中心1中按 照A、 B的順序進(jìn)行處理，在服務(wù)器中心2中按照B、 A的順序進(jìn)行 處理的情況。最初，設(shè)在2個(gè)服務(wù)器中心中數(shù)據(jù)X是0。在服務(wù)器中 心1中由于按照A、 B的順序進(jìn)行處理，因此X的值成為10，而在服 務(wù)器中心2中由于按照B、 A的順序進(jìn)行處理，因此X的值成為1。 在各個(gè)服務(wù)器中心中保持不同的結(jié)果這一點(diǎn)是不能接受的。
現(xiàn)實(shí)中，在相互依賴的事務(wù)或完全沒有關(guān)系的事務(wù)相混合，事務(wù) 處理請(qǐng)求到達(dá)的階段中，并不知道其與其它的哪個(gè)事務(wù)存在依賴關(guān) 系。因此，需要在所有的服務(wù)器中按照相同的順序處理所有的事務(wù)處 理請(qǐng)求。為了實(shí)現(xiàn)這一點(diǎn)，在每次事務(wù)處理請(qǐng)求到達(dá)時(shí)，在所有服務(wù) 器中取得同步，進(jìn)行順序確認(rèn)。進(jìn)而由于在各服務(wù)器中，必須按照在 所有服務(wù)器中取得同步的順序進(jìn)行處理，因此按照其順序一個(gè)一個(gè)地 處理所有的事務(wù)處理。這樣做將使事務(wù)處理的工作效率急劇下降。
圖5表示作為本發(fā)明的一個(gè)實(shí)施形態(tài)的事務(wù)處理系統(tǒng)(處理機(jī)構(gòu))的概略。
事務(wù)處理系統(tǒng)50是服務(wù)器中心內(nèi)的主要遍及DB服務(wù)器、應(yīng)用 服務(wù)器的處理機(jī)構(gòu)。事務(wù)處理系統(tǒng)50如圖所示，在功能上分為事務(wù) 開始處理機(jī)構(gòu)51、事務(wù)提交處理機(jī)構(gòu)52以及有效期間設(shè)定機(jī)構(gòu)53。 有效期間設(shè)定機(jī)構(gòu)53包括對(duì)于客戶端或者應(yīng)用服務(wù)器進(jìn)行設(shè)定的機(jī) 構(gòu)。
首先，事務(wù)開始處理機(jī)構(gòu)51包括控制單元51a、事務(wù)重復(fù)檢測(cè) 單元51b、 Token排斥控制單元51c、數(shù)據(jù)匹配處理單元51d。
事務(wù)重復(fù)檢測(cè)單元51b在事務(wù)的開始處理中，參照對(duì)象事務(wù)的 ID，確認(rèn)是否已經(jīng)正在執(zhí)行同一 ID的事務(wù)，或者已經(jīng)完成提交，如 果是正在執(zhí)行或者已經(jīng)完成提交，則對(duì)于事務(wù)開始請(qǐng)求應(yīng)答回退。
Token排斥控制單元51c在事務(wù)的開始處理中進(jìn)行處理權(quán)限 Token的排斥控制，在該處理權(quán)限Token的排斥控制中，確認(rèn)自身服 務(wù)器中心是否保持沒有用盡有效期間的處理權(quán)限Token (帶時(shí)間限制 的Token),如果沒有保持，則進(jìn)行處理權(quán)限Token的取得處理，等
待到其取得結(jié)束。
數(shù)據(jù)匹配處理單元51d在進(jìn)行上述的處理權(quán)限Token的取得處 理時(shí)，與該處理同時(shí)或者緊接在其以后，控制自身服務(wù)器中心保持在 系統(tǒng)內(nèi)的所有服務(wù)器中心之間最新的數(shù)據(jù)的數(shù)據(jù)匹配。
其次，事務(wù)提交處理機(jī)構(gòu)52包括數(shù)據(jù)復(fù)制處理單元52b、提交 確定處理單元52c以及提交發(fā)送單元52d。
數(shù)據(jù)復(fù)制處理單元52b進(jìn)行將對(duì)象事務(wù)的事務(wù)ID、該事務(wù)所更 新的數(shù)據(jù)和向該事務(wù)的請(qǐng)求源返送的處理結(jié)果向所有的服務(wù)器中心 傳送，確認(rèn)至少對(duì)于F + 1臺(tái)服務(wù)器的拷貝的處理，管理各數(shù)據(jù)庫的 復(fù)制處理。
提交確定處理單元52c控制這樣的處理，即，在由數(shù)據(jù)復(fù)制處理 單元52b對(duì)于數(shù)據(jù)庫的拷貝成功了的情況下，向其它所有的服務(wù)器發(fā) 送提交請(qǐng)求消息，如果接收到至少來自F + l臺(tái)服務(wù)器的提交合意， 則作為提交成功的處理。進(jìn)而，提交發(fā)送單元52d向其它所有的服務(wù)器中心發(fā)送該提交被 確定了的情況。進(jìn)而，有效期間設(shè)定機(jī)構(gòu)53包括控制單元53a、事務(wù)再次發(fā)送 時(shí)間設(shè)定單元53b、 Token有效期間設(shè)定單元53c、客戶端通信單元 53d。事務(wù)再次發(fā)送時(shí)間設(shè)定單元53b是在從DB服務(wù)器看到的客戶 端(應(yīng)用服務(wù)器或者客戶端終端)中設(shè)定事務(wù)的再次發(fā)送時(shí)間(最大 等待時(shí)間)的機(jī)構(gòu)。例如，在系統(tǒng)構(gòu)成時(shí)，可以向各客戶端裝置發(fā)送 存儲(chǔ)再次發(fā)送時(shí)間的設(shè)定畫面。Token有效期間設(shè)定單元53c是設(shè)定在系統(tǒng)內(nèi)的各服務(wù)器中心內(nèi) 使用的處理權(quán)限Token的有效時(shí)間的機(jī)構(gòu)。即，以所給出的事務(wù)再次 發(fā)送時(shí)間為基準(zhǔn)，提供設(shè)定Token的有效時(shí)間的單元。例如，可以在 系統(tǒng)結(jié)構(gòu)設(shè)定畫面中由管理者輸入Token有效時(shí)間作為參數(shù)，進(jìn)行所 輸入的參數(shù)對(duì)于事務(wù)再次發(fā)送時(shí)間是否妥當(dāng)?shù)臋z查。關(guān)于這些設(shè)定時(shí) 間的參數(shù)的例子在后面敘述。另外，以上的處理機(jī)構(gòu)終究是一個(gè)例子，并不限于該結(jié)構(gòu)。圖6表示由圖5的事務(wù)重復(fù)檢測(cè)單元51b決定了的最初一側(cè)的服 務(wù)器中心與備用一側(cè)的服務(wù)器中心之間的消息的交換。另外，該圖表 示進(jìn)行最初服務(wù)器中心60a與備用服務(wù)器中心60b的消息收發(fā)的以下 的各處理單元。最初服務(wù)器中心60a具備向備用服務(wù)器中心60b發(fā)送處理權(quán)限 Token取得請(qǐng)求消息67a的Token請(qǐng)求發(fā)送單元61、接收對(duì)于Token 取得請(qǐng)求的處理權(quán)限Token取得請(qǐng)求應(yīng)答消息67b的Token應(yīng)答接 收單元、發(fā)送提交請(qǐng)求消息68a的提交請(qǐng)求發(fā)送單元64以及接收提 交請(qǐng)求應(yīng)答消息68b的提交請(qǐng)求應(yīng)答接收單元65。另外，備用服務(wù)器中心60b具備從最初服務(wù)器中心接收Token 請(qǐng)求消息，發(fā)送對(duì)于該請(qǐng)求的應(yīng)答的Token請(qǐng)求處理單元63、接收 提交請(qǐng)求消息的提交請(qǐng)求處理單元66。用后述的流程圖說明上述各消息的發(fā)送單元、接收單元的細(xì)節(jié)。本發(fā)明的一個(gè)實(shí)施形態(tài)如用圖5中說明過的那樣，如果從實(shí)際安裝的觀點(diǎn)來看，由事務(wù)開始處理機(jī)構(gòu)、提交控制機(jī)構(gòu)、再次發(fā)送Token 有效期間設(shè)定機(jī)構(gòu)(有效期間設(shè)定機(jī)構(gòu))這3個(gè)構(gòu)成。 [l.事務(wù)開始處理機(jī)構(gòu)]該機(jī)構(gòu)的中心是處理權(quán)限Token的管理機(jī)構(gòu)。處理權(quán)限Token基本上是這樣一種機(jī)構(gòu)，即，保證在某個(gè)時(shí)刻 具有該處理權(quán)限Token的服務(wù)器中心是一個(gè)，而且，保證即使在服務(wù) 器中心中發(fā)生故障，在系統(tǒng)整體中也不會(huì)漏掉事務(wù)的提交的結(jié)果而移 交給其余的服務(wù)器中心。在各服務(wù)器中心中，存在一個(gè)正在工作的處理權(quán)限Token管理 機(jī)構(gòu)。在該機(jī)構(gòu)停止的情況下，視為服務(wù)器中心的停止。提供處理權(quán) 限Token的單位對(duì)于這樣的數(shù)據(jù)集合進(jìn)行提供，即，作為某個(gè)事務(wù)的 集合訪問的數(shù)據(jù)集合，該事務(wù)集合以外的事務(wù)不會(huì)進(jìn)行訪問而且該事 務(wù)集合內(nèi)的任意的事務(wù)不會(huì)訪問該數(shù)據(jù)集合以外的數(shù)據(jù)那樣的數(shù)據(jù) 集合。典型地考慮應(yīng)用單位。在本發(fā)明中，在處理權(quán)限Token管理中使用依據(jù)多數(shù)決定的保 持者決定方式。由此，即使一個(gè)服務(wù)器中心因故障而停止，也知道當(dāng) 前哪個(gè)服務(wù)器中心保持處理權(quán)限Token。另外，在處理權(quán)限Token中設(shè)置有效期間。由此，即使當(dāng)前正 在保持處理權(quán)限Token的服務(wù)器中心因故障而停止，但如果經(jīng)過某時(shí) 間，其它的服務(wù)器中心能夠取得處理權(quán)限Token,其它的服務(wù)器中心 能夠執(zhí)行事務(wù)處理。另外，在處理權(quán)限Token中設(shè)置作為連續(xù)號(hào)碼(通番)的TSN (Token系列號(hào))。另夕卜，如事務(wù)日志中已經(jīng)敘述的那樣，提供LSN(日志系列號(hào))， 當(dāng)取得處理權(quán)限Token時(shí)，保持了前一次處理權(quán)限Token的服務(wù)器 中心能夠取得最終提交的事務(wù)日志。由此，能夠不丟失提交完畢的事 務(wù)曰志而繼續(xù)執(zhí)行。以下表示取得處理權(quán)限Token的處理。<處理權(quán)限Token取得請(qǐng)求消息發(fā)送處理70 >本處理由圖6的Token請(qǐng)求發(fā)送單元61進(jìn)行。以下，參照?qǐng)D7 的流程圖詳細(xì)說明。1) 在有其它的服務(wù)器中心保持著處理權(quán)限Token這樣的記錄的 情況下(步驟S71:"是")，等待到該處理權(quán)限Token的有效期間 用盡為止(步驟S72)。2) 記錄當(dāng)前時(shí)刻，3) 決定處理權(quán)限Token的有效期間(步驟S73 )。4) 從當(dāng)前記錄在自身服務(wù)器中心中的最新的處理權(quán)限Token, 取得其TSN，根據(jù)下述的方法決定TSN，作為新的處理權(quán)限Token 的TSN提供。(a )如果判斷為自身服務(wù)器中心直到緊接之前為止保持了處理 權(quán)限Token，則把其處理權(quán)限Token的TSN作為新的TSN(步驟S75 )。(b)否則的情況下，把在直到緊接之前為止的處理權(quán)限Token 的TSN上加1的值作為新的處理權(quán)限Token的TSN (步驟S76 )。5) 在自身服務(wù)器中心中，確定是提交還是回退，進(jìn)而，在事務(wù) 曰志的LSN中沒有遺漏地連續(xù)的事務(wù)日志的集合內(nèi)提供事務(wù)日志的 LSN的最大值和處理權(quán)限Token的有效期間，向自身以外的所有服務(wù) 器中心發(fā)送處理權(quán)限Token取得請(qǐng)求(步驟S77 )。<對(duì)于處理權(quán)限Token取得請(qǐng)求消息的應(yīng)答消息接收處理80 >本處理由圖6的Token應(yīng)答接收單元62進(jìn)行。以下，參照?qǐng)D8 的流程圖詳細(xì)說明。1)當(dāng)對(duì)于接收到的處理權(quán)限Token取得請(qǐng)求的應(yīng)答消息內(nèi)的事 務(wù)曰志的LSN與在自身服務(wù)器中心中在事務(wù)曰志的LSN中沒有遺漏 地連續(xù)的事務(wù)日志的集合內(nèi)的事務(wù)日志的LSN的最大值相比更大的 情況下(步驟S81:"是")，從處理權(quán)限Token取得請(qǐng)求的應(yīng)答消 息，取出差分的事務(wù)日志，反映數(shù)據(jù)(步驟S82)。2 )如果從一個(gè)以上的服務(wù)器中心接收到處理權(quán)限Token取得許 可(步驟S83:"是")，則作為處理權(quán)限Token取得成功，把在步 驟S73中記錄了的時(shí)刻上加上處理權(quán)限Token的有效期間的時(shí)刻作為處理權(quán)限Token的有效期限進(jìn)行記錄(步驟S84)。進(jìn)而，取得應(yīng)答 消息內(nèi)的處理權(quán)限Token的TSN，把其值和在步驟S75、 S76中提供 的值中的大的值作為處理權(quán)限Token的TSN記錄后結(jié)束(步驟S85 )。 3)在接收到來自2個(gè)服務(wù)器中心的處理權(quán)限Token取得拒絕的 情況下(步驟S86:"是")，作為處理權(quán)限Token取得失敗而結(jié)束。 4 )在接收到再次發(fā)送委托，并且還沒有能夠取得處理權(quán)限Token 的情況下(步驟S87:"否")，判斷是否應(yīng)該再次發(fā)送，如果應(yīng)該 再次發(fā)送(步驟S89:"是")，則等待一定時(shí)間，從步驟S71開始 執(zhí)行(僅在接收到再次發(fā)送委托的情況下到達(dá)該步驟)。5)在即使經(jīng)過某一定時(shí)間也不能決定處理權(quán)限取得的成功 失 敗的情況下(步驟S88:"否")，作為處理權(quán)限Token取得失敗， 判斷是否應(yīng)該再次發(fā)送，如果應(yīng)該再次發(fā)送(步驟S89:"是")， 則經(jīng)過一定時(shí)間以后，從步驟S71起再次執(zhí)行。以下，表示對(duì)于處理權(quán)限Token取得請(qǐng)求的接收處理的算法。 <處理權(quán)限Token取得請(qǐng)求消息接收處理卯> 本處理由圖6的Token請(qǐng)求處理單元63進(jìn)行。以下，參照?qǐng)D9、 圖10的流程圖詳細(xì)說明。1) 如果自身服務(wù)器中心正在進(jìn)行處理權(quán)限Token取得處理(步 驟S91:"是")，則返送再次發(fā)送委托后結(jié)束(步驟S92)。2) 把處理權(quán)限Token取得請(qǐng)求的消息內(nèi)的事務(wù)日志的LSN與 自身服務(wù)器中心保持的事務(wù)日志的LSN中沒有遺漏而連續(xù)的LSN的 集合的最大值進(jìn)行比較，進(jìn)行以下的處理。(a) 在自身服務(wù)器中心的事務(wù)曰志的LSN大的情況下(步驟 S93:"是")，把發(fā)送源的服務(wù)器中心不具有的事務(wù)日志加入到應(yīng) 答消息中(步驟S94)。(b) 在自身服務(wù)器中心具有當(dāng)前正在提交處理的事務(wù)，其事務(wù) 曰志的LSN比接收到的事務(wù)曰志的LSN小的情況下(步驟S95:"是，，)，將該事務(wù)設(shè)為提交結(jié)束(步驟S96)。3 )在自身服務(wù)器中心具有有效期限內(nèi)的處理權(quán)限Token的情況下(步驟S97:"是")，把處理權(quán)限Token取得拒絕加入到應(yīng)答消 息中，返送后結(jié)束(步驟S98)。4) 在自身服務(wù)器中心具有發(fā)送源服務(wù)器中心以外的服務(wù)器中心 具有有效期限內(nèi)的處理權(quán)限Token這樣的記錄的情況下(步驟S99:"是")，把處理權(quán)限Token取得拒絕加入到應(yīng)答消息中返送后結(jié)束 (步驟S100)5) 在自身服務(wù)器中心具有正在提交處理的事務(wù)的情況下(步驟 S101:"是")，把再次發(fā)送委托加入到應(yīng)答消息中，返送后結(jié)束(步 驟S102)。6) 把在當(dāng)前時(shí)刻上加上提供到處理權(quán)限Token取得請(qǐng)求的有效 期間的時(shí)刻作為處理權(quán)限Token的有效期限進(jìn)行記錄，進(jìn)而根據(jù)下述 的方法，決定新的處理權(quán)限Token的TSN,記錄其值(步驟S103 )。(a) 在接收到的處理權(quán)限Token取得消息內(nèi)的TSN比在自身 服務(wù)器中心中記錄的最新的處理權(quán)限Token的TSN大的情況下(步 驟S104:"是")，把接收到的處理權(quán)限Token取得消息內(nèi)的TSN 作為新的處理權(quán)限Token的TSN (步驟S105 )。(b) 在接收到的處理權(quán)限Token取得消息內(nèi)的TSN與在自身 服務(wù)器中心中記錄的最新的處理權(quán)限Token的TSN相同，發(fā)送源的 服務(wù)器中心與在自身服務(wù)器中心中記錄的保持最新的處理權(quán)限Token 的服務(wù)器中心相同的情況下(步驟S107:"是")，把在自身服務(wù)器 中心中記錄的最新的處理權(quán)限Token的TSN的值作為新的處理權(quán)限 Token的TSN (步驟S108 )。(c) 在不屬于上述2種情況時(shí)，把在自身服務(wù)器中心的處理權(quán) 限Token的TSN上加1的值作為新的處理權(quán)限Token的TSN (步驟5109) 。7) 把"處理權(quán)限Token取得明白"和在步驟S103 ~ S109中決定 了的處理權(quán)限Token的TSN加入到應(yīng)答消息中，返送后結(jié)束(步驟5110) 。由于在處理權(quán)限Token中存在有效期間，因此如果經(jīng)過該期間，則當(dāng)前的處理權(quán)限Token成為時(shí)間用盡，即使保持該處理權(quán)限Token 的服務(wù)器中心變?yōu)楣δ懿蝗?，下一個(gè)服務(wù)器中心也能獲得處理權(quán)限 Token。
這里，重要的一點(diǎn)在于在發(fā)送源服務(wù)器中心中，把處理權(quán)限 Token的有效期限取為在請(qǐng)求發(fā)送前的時(shí)刻上加上了處理權(quán)限Token 的有效期間得到的值，而且，在接收了請(qǐng)求一側(cè)的服務(wù)器中心中，取 為在該請(qǐng)求的接收時(shí)刻上加上了處理權(quán)限Token的有效期間得到的 值。由此，在接收一側(cè)，保證在處理權(quán)限Token成為期限用盡的時(shí)刻， 已經(jīng)用盡當(dāng)前的處理權(quán)限Token的有效期限。即，即使不確認(rèn)保持當(dāng) 前處理權(quán)限Token的服務(wù)器中心生存這一點(diǎn)，其它的服務(wù)器中心也能 確認(rèn)處理權(quán)限Token的有效期限用盡，能夠?qū)θ〉孟乱粋€(gè)處理權(quán)限 Token或者取得請(qǐng)求發(fā)出許可。 [2.提交控制機(jī)構(gòu)]
在提交處理中，向其它2個(gè)服務(wù)器中心發(fā)送事務(wù)日志，如果從一 個(gè)以上的服務(wù)器中心接收到"明白，，則作為提交成功。由于假定服務(wù)器 中心是3個(gè)，因此如果發(fā)送了事務(wù)日志的服務(wù)器中心和其它另 一個(gè)服 務(wù)器中心進(jìn)行"提交明白"，則可以得到過半數(shù)的"提交明白"，從而能 夠以來自 一個(gè)以上的服務(wù)器中心的"提交明白"，作為系統(tǒng)整體可明白 提交。
以下表示提交處理。這里，設(shè)在事務(wù)上提供了在系統(tǒng)內(nèi)成為唯一 的事務(wù)ID。另外，在下述的算法中沒有包括對(duì)客戶端的返送處理，但 在提交處理結(jié)束以后，對(duì)客戶端應(yīng)答事務(wù)的處理結(jié)果。這時(shí)，即使開 始了提交處理的事務(wù)進(jìn)行回退，當(dāng)已經(jīng)存在具有同一事務(wù)ID的事務(wù) 日志時(shí)，從該事務(wù)日志取得處理結(jié)果返送給客戶端。
<提交請(qǐng)求消息發(fā)送處理110 >
本處理由圖6的提交請(qǐng)求發(fā)送單元64進(jìn)行。以下，參照?qǐng)D11 的流程圖詳細(xì)說明。
1)如果已經(jīng)在自身服務(wù)器中心中對(duì)于同一個(gè)事務(wù)完成了提交處 理(步驟S111:"是，，)，則應(yīng)答回退后結(jié)束(步驟S112)。2) 如果已經(jīng)從其它服務(wù)器中心接收到具有同一個(gè)事務(wù)ID的確 定了提交的事務(wù)日志(步驟S113:"是")，或者對(duì)于同一個(gè)事務(wù)， 在自身服務(wù)器中心中應(yīng)答了"提交明白"(步驟S114:"是")，則應(yīng) 答回退后結(jié)束(步驟S112)。
3) 如果不具有有效的處理權(quán)限Token (步驟S115:"否")， 則應(yīng)答回退后結(jié)束(步驟S112)。
4) 在沒有再次發(fā)送事務(wù)日志的情況下(步驟S116:"否")， 與事務(wù)ID、事務(wù)日志的LSN—起把事務(wù)日志加入到發(fā)送消息中(步 驟S117)。
5) 如果處理權(quán)限Token的有效期限小于等于一定時(shí)間(步驟 S118:"是")，則進(jìn)行下述的處理(步驟S119)。
(a) 記錄當(dāng)前時(shí)刻。
(b) 決定有效期間。
(c )包括有效期間和處理權(quán)限Token的TSN在內(nèi)，把處理權(quán)限 Token繼續(xù)請(qǐng)求加入到發(fā)送消息中。
6) 把發(fā)送消息向其它的服務(wù)器中心發(fā)送(步驟S119a)。 <對(duì)提交請(qǐng)求的應(yīng)答消息接收處理120 >
本處理由圖6的提交請(qǐng)求應(yīng)答接收單元65進(jìn)行。以下，參照?qǐng)D 12的流程圖詳細(xì)說明。
1) 如果在返送消息中包括"繼續(xù)明白"(步驟S121:"是，，)， 則把在上述步驟S119中記錄的時(shí)刻上加上了處理權(quán)限Token的有效 期限得到的時(shí)刻作為有效期限進(jìn)行記錄(步驟S122)。
2) 如果從一個(gè)以上的服務(wù)器中心接收到"提交明白"的應(yīng)答(步 驟123:"是")，則作為提交成功，記錄其事務(wù)日志和其LSN后結(jié) 束(步驟S124)。
3) 如果從一個(gè)以上的服務(wù)器中心接收到提交拒絕的應(yīng)答(步驟 S125:"是")，則作為回退，把其事務(wù)日志的LSN作為回退進(jìn)行 記錄后結(jié)束(步驟S128)。
4) 在即使等待某一定期間也沒能接收到來自某個(gè)服務(wù)器中心的應(yīng)答的情況下(步驟S126:"否")，則判斷是否應(yīng)該再次發(fā)送，如 果是應(yīng)該再次發(fā)送(步驟S127:"是")，則在經(jīng)過一定時(shí)間以后， 從步驟Slll起再次執(zhí)行。否則的情況下，作為回退，把其事務(wù)日志 的LSN作為回退進(jìn)行記錄后結(jié)束(步驟S128)。
以下表示在接收到提交處理請(qǐng)求的服務(wù)器中心中的處理。
<提交請(qǐng)求消息接收處理130 >
本處理由圖6的提交請(qǐng)求處理單元66進(jìn)行。以下參照?qǐng)D13的流 程圖詳細(xì)說明。
1) 如果在自身服務(wù)器中心中已經(jīng)進(jìn)行具有同一個(gè)事務(wù)ID的事 務(wù)的提交處理(步驟S131:"是")，則返送提交拒絕并結(jié)束(步驟 S132)。
2) 如果從其它的服務(wù)器中心已經(jīng)接收具有同一個(gè)事務(wù)ID的事 務(wù)日志，并且對(duì)于該日志應(yīng)答了"提交明白，，(步驟S133:"是")， 則返送提交拒絕并結(jié)束(步驟S132)。
3) 如果自身服務(wù)器中心正在進(jìn)行處理權(quán)限Token取得處理(步 驟S134:"是")，則返送再次發(fā)送委托后結(jié)束(步驟S135)。
4) 在接收到的消息內(nèi)的處理權(quán)限Token的TSN比自身服務(wù)器 中心中記錄的處理權(quán)限Token的TSN小的情況下(步驟S136:"是")， 把在自身服務(wù)器中心的記錄中的當(dāng)前的處理權(quán)限Token保持服務(wù)器 中心和其TSN包含在應(yīng)答消息中，將提交拒絕返送后結(jié)束(步驟 S137)。
5) 在所接收到的消息內(nèi)的處理權(quán)限Token的TSN比自身服務(wù) 器中心中記錄的當(dāng)前的處理權(quán)限Token的TSN大的情況下(步驟 S138:"是")，把在當(dāng)前時(shí)刻上加上了處于接收到的消息內(nèi)的處理 權(quán)限Token的有效期間的時(shí)刻作為有效期限，把處理權(quán)限Token保 持服務(wù)器中心作為消息的發(fā)送源服務(wù)器中心來進(jìn)行記錄(步驟S139 )。
6) 如果其它的服務(wù)器中心沒有保持處理權(quán)限Token(步驟S140: "是")，則進(jìn)行以下的處理。
(a )把在當(dāng)前時(shí)刻上加上了提供給處理權(quán)限Token繼續(xù)請(qǐng)求的有效期間的時(shí)刻記錄為處理權(quán)限Token的有效期限(步驟S141)。 (b)把"繼續(xù)明白"包含在返送消息中(步驟S142)。 7)把接收到的事務(wù)ID及其事務(wù)日志作為"提交明白"來記錄，
返送"提交明白"(步驟S143， S144)。
在本發(fā)明中，從客戶端來看，即使一個(gè)服務(wù)器中心發(fā)生了故障， 在不知道該故障的程度的時(shí)間內(nèi)必須應(yīng)答事務(wù)處理的結(jié)果。這里，所 謂r從客戶端來看，不知道服務(wù)器中心的故障的程度的時(shí)間」是按照
應(yīng)用的規(guī)格確定的正常時(shí)的最大應(yīng)答時(shí)間。例如，是3秒左右的時(shí)間。 為了保證這一點(diǎn)，需要適當(dāng)?shù)卦O(shè)定事務(wù)處理的暫停時(shí)間、處理權(quán)限 Token的有效期間和客戶端的直到再次發(fā)送為止的等待時(shí)間。以下表 示其一個(gè)例子。現(xiàn)在，如果設(shè)客戶端的事務(wù)處理的最大等待時(shí)間為T，處理權(quán)限 Token的有效期間為Tt。，事務(wù)處理的暫停時(shí)間為Ttx，客戶端的直到 再次發(fā)送為止的等待時(shí)間為Tew，則下面的式子成立。 T^max (Tcw， Tt0) + Ttx (式1)
Tcw>Ttx (式2) Tt0 > Ttx (式3 )
進(jìn)而，當(dāng)由客戶端進(jìn)行再次發(fā)送，向不是最初的服務(wù)器中心傳送 時(shí)，為了用盡最初的處理權(quán)限Token的有效期限，使得接受了再次發(fā) 送請(qǐng)求的服務(wù)器中心能夠獲得處理權(quán)限Token,添加下述的公式。 Tcw > Tt0 (式4 )
只要確定Ttx、 Tew, Tt。，使得滿足該(式l)、(式2)、(式 3)、(式4)即可。其中，(式4)不是必須的。
例如，如果設(shè)T為3000msec，則能夠把U殳定為1400 msec, 把U殳定為1500 msec,把T^設(shè)定為1600 msec。
有效期間設(shè)定機(jī)構(gòu)既可以使管理者經(jīng)由專用畫面輸入這樣的時(shí) 間值，也可以以所提供的T為基準(zhǔn)計(jì)算并顯示滿足上述式子的值，進(jìn) 而由管理者進(jìn)行調(diào)整。所決定的時(shí)間值在各個(gè)服務(wù)器中心中發(fā)送并共用。
以上，使用實(shí)施形態(tài)以及實(shí)施例說明了本發(fā)明，但是本發(fā)明的技 術(shù)范圍并不限于上述實(shí)施形態(tài)中記載的范圍。能夠在上述實(shí)施形態(tài)上 添加多種變更或者改良。另外，從權(quán)利要求范圍的記載明確了添加了 這種變更或者改良的形態(tài)也包含在本發(fā)明的技術(shù)范圍內(nèi)。
作為本發(fā)明的一個(gè)實(shí)施形態(tài)所說明的事務(wù)處理方法能夠由計(jì)算 機(jī)上的系統(tǒng)或者使其計(jì)算機(jī)執(zhí)行其功能的程序來實(shí)現(xiàn)。另外，保存上 述程序的計(jì)算機(jī)可讀取的記錄介質(zhì)能夠是電子的、磁的、光學(xué)的、電 磁的、紅外線或半導(dǎo)體系統(tǒng)(或者，裝置或設(shè)備)或者傳輸介質(zhì)。在 計(jì)算機(jī)可讀取的記錄介質(zhì)的例子中，包括半導(dǎo)體或者固態(tài)存儲(chǔ)裝置、 磁帶，在可裝卸的計(jì)算機(jī)可讀取的介質(zhì)的例子中，包括半導(dǎo)體或者固
態(tài)存儲(chǔ)裝置、磁帶、可裝卸的計(jì)算機(jī)軟盤、隨機(jī)訪問存儲(chǔ)器(RAM)、 只讀存儲(chǔ)器(ROM)、硬磁盤以及光盤。在當(dāng)前的光盤的例子包括 密致盤-只讀存儲(chǔ)器(CD-ROM)、密致盤-讀/寫(CD-R/W) 以及DVD。
權(quán)利要求
1.一種事務(wù)處理方法，是在由連接到網(wǎng)絡(luò)上的多個(gè)客戶端和多個(gè)服務(wù)器中心構(gòu)成的計(jì)算機(jī)系統(tǒng)中的事務(wù)處理方法，其特征在于，上述服務(wù)器中心至少由一個(gè)數(shù)據(jù)庫、管理該數(shù)據(jù)庫的DB服務(wù)器、以及與上述DB服務(wù)器和上述客戶端交互通信的一個(gè)以上的應(yīng)用服務(wù)器構(gòu)成，上述事務(wù)處理方法包括根據(jù)從上述客戶端經(jīng)由上述應(yīng)用服務(wù)器的事務(wù)開始請(qǐng)求，參照該事務(wù)的ID，判斷同一ID的事務(wù)是否已經(jīng)正在執(zhí)行或已經(jīng)完成提交，如果上述同一ID的事務(wù)正在執(zhí)行或者已經(jīng)完成提交，則對(duì)于該事務(wù)開始請(qǐng)求應(yīng)答回退的步驟；確認(rèn)自身服務(wù)器中心是否保持著有效的處理權(quán)限Token，如果沒有保持上述處理權(quán)限Token，則向上述自身服務(wù)器中心以外的其它所有的服務(wù)器中心發(fā)行上述處理權(quán)限Token的取得請(qǐng)求，等待從過半數(shù)的服務(wù)器中心完成該取得請(qǐng)求的步驟；在取得上述處理權(quán)限Token時(shí)，上述自身服務(wù)器中心在上述其它所有的服務(wù)器中心之間進(jìn)行數(shù)據(jù)匹配的步驟。
2. 根據(jù)權(quán)利要求l所述的事務(wù)處理方法，其特征在于， 上述事務(wù)處理方法還包括向所有的上述服務(wù)器中心傳送對(duì)象事務(wù)的上述事務(wù)ID、該事務(wù) 更新的數(shù)據(jù)、向該事務(wù)的請(qǐng)求源返送的處理結(jié)果，確認(rèn)至少在過半數(shù) 的服務(wù)器中心中的上述數(shù)據(jù)庫中拷貝了上述數(shù)據(jù)的步驟；在上述進(jìn)行確認(rèn)的步驟中確認(rèn)成功了的情況下，向上述其它所有 的服務(wù)器中心發(fā)送提交請(qǐng)求的消息，在接收到來自過半數(shù)的服務(wù)器中 心的提交合意的情況下，判斷為上述提交請(qǐng)求成功的步驟；向上述其它所有的服務(wù)器中心發(fā)送上述進(jìn)行判斷的步驟所確定 的提交的結(jié)果的步驟。
3. 根據(jù)權(quán)利要求2所述的事務(wù)處理方法，其特征在于，還包括在上述處理權(quán)限Token的取得處理中接收到上述提交請(qǐng)求的情 況下，直到上述處理權(quán)限Token的取得處理完成為止，不進(jìn)行對(duì)該提 交請(qǐng)求的回信，或者進(jìn)述提交請(qǐng)求的消息的再次發(fā)送委托的步 驟。
4. 根據(jù)權(quán)利要求2所述的事務(wù)處理方法，其特征在于，還包括 在向上述其它所有的服務(wù)器中心發(fā)送上述提交請(qǐng)求的消息、接收其應(yīng)答而確定提交之前的期間中，當(dāng)接收到上述處理權(quán)限Token的取 得消息時(shí)，直到該提交確定為止，不進(jìn)行對(duì)上述處理權(quán)限Token的取 得消息的回信，或者進(jìn)行上述處理權(quán)限Token的取得消息的再次發(fā)送 委托的步驟。
5. 根據(jù)權(quán)利要求l所述事務(wù)處理方法，其特征在于，還包括 在上述處理權(quán)限Token的取得完成之前，從其它的上述服務(wù)器中心接收未確定的事務(wù)日志，使上述未確定的事務(wù)日志的狀態(tài)同步的 步驟。
6. 根據(jù)權(quán)利要求2所述的事務(wù)處理方法，其特征在于，還包括 在接收上述處理權(quán)限Token的取得請(qǐng)求消息以及接收該處理權(quán)限Token的取得請(qǐng)求應(yīng)答消息時(shí)，在上述消息中包括提交不明確的事 務(wù)信息的情況下，參照上述事務(wù)信息，在該事務(wù)的提交或者回退已經(jīng) 確定的情況下，返送其結(jié)果的步驟。
7. 根據(jù)權(quán)利要求2所述的事務(wù)處理方法，其特征在于，還包括 對(duì)上述提交請(qǐng)求的消息，判斷該提交請(qǐng)求的消息的發(fā)送源以外是否保持著有效的上述處理權(quán)限Token,如果是保持著則對(duì)提交請(qǐng)求應(yīng) 答拒絕，如果沒有保持則應(yīng)答承認(rèn)的步驟。
8. 根據(jù)權(quán)利要求l所述的事務(wù)處理方法，其特征在于，還包括 把發(fā)送上述事務(wù)開始請(qǐng)求的客戶端的事務(wù)再次發(fā)送時(shí)間和上述處理權(quán)限Token的有效期間設(shè)定在上述客戶端中的步驟。
9. 根據(jù)權(quán)利要求l所述的事務(wù)處理方法，其特征在于， 上述處理權(quán)限Token是包括了有效期限的帶時(shí)間限制的Token。
10. —種事務(wù)處理系統(tǒng)，該事務(wù)處理系統(tǒng)由連接到網(wǎng)絡(luò)上的多個(gè)客戶端和多個(gè)服務(wù)器中心構(gòu)成，其特征在于，上述服務(wù)器中心至少由一個(gè)數(shù)據(jù)庫、管理該數(shù)據(jù)庫的DB服務(wù) 器、以及與上述DB服務(wù)器交互通信的一個(gè)以上的應(yīng)用服務(wù)器構(gòu)成， 上述事務(wù)處理系統(tǒng)具備事務(wù)重復(fù)檢測(cè)單元，根據(jù)從上述客戶端經(jīng)由上述應(yīng)用服務(wù)器的事 務(wù)開始請(qǐng)求，參照該事務(wù)的ID，判斷同一ID的事務(wù)是否已經(jīng)正在執(zhí) 行或已經(jīng)完成提交，如果上述同一 ID的事務(wù)正在執(zhí)行或者已經(jīng)完成 提交，則對(duì)該事務(wù)開始請(qǐng)求應(yīng)答回退；Token排斥控制單元，確認(rèn)自身服務(wù)器中心是否保持著有效的處 理權(quán)限Token,如果沒有保持上述處理權(quán)限Token,則向上述自身服 務(wù)器中心以外的其它所有的服務(wù)器中心發(fā)行上述處理權(quán)限Token的 取得請(qǐng)求，等待從過半數(shù)的服務(wù)器中心完成該取得請(qǐng)求；數(shù)據(jù)匹配處理單元，在取得上述處理權(quán)限Token時(shí)，上述自身 服務(wù)器中心在所有的上述服務(wù)器中心之間進(jìn)行數(shù)據(jù)匹配，進(jìn)而，上述事務(wù)處理系統(tǒng)在上述事務(wù)的提交處理中，具備數(shù)據(jù)復(fù)制處理單元，向上述其它所有的服務(wù)器中心傳送對(duì)象事務(wù) 的上述事務(wù)ID、該事務(wù)更新的數(shù)據(jù)、向該事務(wù)的請(qǐng)求源返送的處理結(jié) 果，確認(rèn)至少在過半數(shù)的服務(wù)器中心中的上述數(shù)據(jù)庫中拷貝了上述數(shù) 據(jù)；提交確定處理單元，在由上述數(shù)據(jù)復(fù)制處理單元進(jìn)行的確認(rèn)成功 了的情況下，向上述其它所有的服務(wù)器中心發(fā)送提交請(qǐng)求的消息，在 接收到來自過半數(shù)的服務(wù)器中心的提交合意的情況下，判斷為上述提 交請(qǐng)求成功；提交發(fā)送單元，向上述其它所有的服務(wù)器中心發(fā)送上述提交確定 處理單元所確定的提交的結(jié)果。
11.根據(jù)權(quán)利要求10所述的事務(wù)處理系統(tǒng)，其特征在于，還具備把發(fā)送上述事務(wù)開始請(qǐng)求的客戶端的事務(wù)再次發(fā)送時(shí)間和上述 處理權(quán)限Token的有效期間設(shè)定在客戶端中的有效期間設(shè)定機(jī)構(gòu)。
12. —種事務(wù)處理裝置，是在由連接到網(wǎng)絡(luò)上的多個(gè)客戶端和多 個(gè)服務(wù)器中心構(gòu)成的計(jì)算機(jī)系統(tǒng)中的事務(wù)處理裝置，其特征在于，上述服務(wù)器中心至少由一個(gè)數(shù)據(jù)庫、管理該數(shù)據(jù)庫的DB服務(wù) 器、以及一個(gè)以上的應(yīng)用服務(wù)器構(gòu)成，上述事務(wù)處理裝置包含在上述DB服務(wù)器中，并具備Token請(qǐng)求發(fā)送單元，根據(jù)來自上述客戶端的經(jīng)由上述應(yīng)用服務(wù) 器的事務(wù)開始請(qǐng)求，為了使上述自身服務(wù)器中心得到訪問上述數(shù)據(jù)庫 的權(quán)限，發(fā)送處理權(quán)限Token取得請(qǐng)求消息；Token應(yīng)答接收單元，接收針對(duì)上述處理權(quán)限Token取得請(qǐng)求 消息的應(yīng)答消息；提交請(qǐng)求發(fā)送單元，發(fā)送提交請(qǐng)求消息；提交應(yīng)答接收單元，接收對(duì)上述提交請(qǐng)求消息的應(yīng)答消息，其中，上述Token請(qǐng)求發(fā)送單元在上述自身服務(wù)器中心沒有保 持處理權(quán)限Token的情況下，向上述自身服務(wù)器中心以外的其它所有 的服務(wù)器中心發(fā)送處理權(quán)限Token取得請(qǐng)求消息，上述Token應(yīng)答接收單元根據(jù)從針對(duì)上述處理權(quán)限Token取得 請(qǐng)求消息的過半數(shù)的服務(wù)器中心接收到應(yīng)答，判斷處理權(quán)限Token的 取得成功、取得失敗，上述提交請(qǐng)求發(fā)送單元在上述處理權(quán)限Token的取得成功了的 情況下，向上述其它所有的服務(wù)器中心發(fā)送包括事務(wù)日志的提交請(qǐng)求 消息，上述提交應(yīng)答接收單元在從過半數(shù)的服務(wù)器中心接收到"明白" 消息的情況下，判斷為提交成功。
13. 根據(jù)權(quán)利要求12所述的事務(wù)處理裝置，其特征在于， 上述處理權(quán)限Token是包括了有效期限的帶時(shí)間限制的Token。
14. 根據(jù)權(quán)利要求12所述的事務(wù)處理裝置，其特征在于，還具備把發(fā)送上述事務(wù)開始請(qǐng)求的客戶端的事務(wù)再次發(fā)送時(shí)間和上述 處理權(quán)限Token的有效期間設(shè)定在上述客戶端中的有效期間設(shè)定機(jī)構(gòu)。
15. —種計(jì)算機(jī)程序，是由連接到網(wǎng)絡(luò)上的多個(gè)客戶端和多個(gè)服 務(wù)器中心構(gòu)成的計(jì)算機(jī)系統(tǒng)中的計(jì)算機(jī)程序，其特征在于，上述服務(wù)器中心至少由一個(gè)數(shù)據(jù)庫、管理該數(shù)據(jù)庫的DB服務(wù) 器、以及與上述DB服務(wù)器和上述客戶端交互通信的一個(gè)以上的應(yīng)用 服務(wù)器構(gòu)成，上述計(jì)算機(jī)程序使計(jì)算機(jī)系統(tǒng)執(zhí)行如下步驟根據(jù)從上述客戶端經(jīng)由上述應(yīng)用服務(wù)器的事務(wù)開始請(qǐng)求，參照該 事務(wù)的ID,判斷同一ID的事務(wù)是否已經(jīng)正在執(zhí)行或已經(jīng)完成提交， 如果上述同一ID的事務(wù)正在執(zhí)行或者已經(jīng)完成提交，則對(duì)于該事務(wù) 開始請(qǐng)求應(yīng)答回退的步驟；確認(rèn)自身服務(wù)器中心是否保持著有效的處理權(quán)限Token,如果沒 有保持上述處理權(quán)限Token,則向上述自身服務(wù)器中心以外的其它所 有的服務(wù)器中心發(fā)行上述處理權(quán)限Token的取得請(qǐng)求，等待從過半數(shù) 的服務(wù)器中心完成該取得請(qǐng)求的步驟；在取得上述處理權(quán)限Token時(shí)，上述自身服務(wù)器中心在所有的 上述服務(wù)器中心之間進(jìn)行數(shù)據(jù)匹配的步驟。
16. 根據(jù)權(quán)利要求15所述的計(jì)算機(jī)程序，其特征在于， 上述計(jì)算機(jī)程序還使計(jì)算機(jī)系統(tǒng)執(zhí)行如下步驟 向所有的上述服務(wù)器中心傳送對(duì)象事務(wù)的上述事務(wù)ID、該事務(wù)更新的數(shù)據(jù)、向該事務(wù)的請(qǐng)求源返送的處理結(jié)果，確認(rèn)至少在過半數(shù) 的服務(wù)器中心中的上述數(shù)據(jù)庫中拷貝了上述數(shù)據(jù)的步驟；在上述進(jìn)行確認(rèn)的步驟中確認(rèn)成功的情況下，向上述其它所有的 服務(wù)器中心發(fā)送提交請(qǐng)求的消息，在接收到來自過半數(shù)的服務(wù)器中心 的提交合意的情況下，判斷為上述提交請(qǐng)求成功的步驟；向上述其它所有的服務(wù)器中心發(fā)送上述進(jìn)行判斷的步驟所確定 的提交的結(jié)果的步驟。
17. 根據(jù)權(quán)利要求15或權(quán)利要求16所述的計(jì)算機(jī)程序，其特征在于，還使計(jì)算機(jī)系統(tǒng)執(zhí)行將發(fā)送上述事務(wù)開始請(qǐng)求的客戶端的事務(wù)再次發(fā)送時(shí)間和上述處理權(quán)限Token的有效期間設(shè)定在上述客戶端 中的步驟。
18. 根據(jù)權(quán)利要求15或17所述的計(jì)算機(jī)程序，其特征在于， 上述處理權(quán)限Token是包括了有效期限的帶時(shí)間限制的Token。
19. 一種記錄介質(zhì)，其特征在于， 記錄了權(quán)利要求14至權(quán)利要求18記栽的計(jì)算機(jī)程序。
全文摘要
本發(fā)明提供一種不間斷事務(wù)處理系統(tǒng)。在業(yè)務(wù)系統(tǒng)中，使由服務(wù)器或者網(wǎng)絡(luò)等故障引起的服務(wù)暫時(shí)中斷的時(shí)間縮短變?yōu)橹匾?，?dāng)前的故障應(yīng)對(duì)一般利用故障檢測(cè)和移交的方式，而由于在故障檢測(cè)中至少需要10秒到幾分鐘的時(shí)間，因此服務(wù)中斷時(shí)間在其以上，成為重大的問題。本發(fā)明提出了不等待故障檢測(cè)，在一定時(shí)間沒有應(yīng)答的情況下，從客戶端向備用的服務(wù)器中心再次發(fā)送處理的系統(tǒng)。本發(fā)明的事務(wù)處理機(jī)構(gòu)具備把使用了處理權(quán)限Token的排斥控制與數(shù)據(jù)匹配相組合的事務(wù)開始處理機(jī)構(gòu)、把基于分散合意的能否提交判斷與更新數(shù)據(jù)的復(fù)制相組合的提交處理機(jī)構(gòu)。依據(jù)該機(jī)構(gòu)提供在故障發(fā)生時(shí)把服務(wù)停止時(shí)間縮短到從客戶端來看服務(wù)沒有停止的程度的時(shí)間的系統(tǒng)。
文檔編號(hào)G06F9/46GK101317163SQ200680044766
公開日2008年12月3日 申請(qǐng)日期2006年11月30日 優(yōu)先權(quán)日2005年11月30日
發(fā)明者堀井洋, 山本學(xué), 田井秀樹 申請(qǐng)人:國際商業(yè)機(jī)器公司