在本節中我們使用事件驅動(Event driven)的方式，說明使用版本集合的資料 暫存方法是如何運作的。使用版本集合的資料暫存方法時，在行動客戶端上共有 三個事件，分別為查詢到達(Query arrival)、驗證報告到達(Invalidation report arrival)與監聽資料到達(Listen data arrival)。我們將依序說明這三個事件的運作方 式。在此之前，我們先介紹各事件的演算法所使用到的符號，再依查詢到達、驗 證報告到達、監聽資料到達的次序依序說明。
首先我們介紹演算法中所使用到的符號。這些符號已經整理如表 4-1。
表 4-1 符號的定義
名稱 描述
VSnew 新版本集合
VScurrent 目前版本集合
VSinvalid 失效版本集合
Data_Item_Set(Query) 查詢 Query 的資料項集合
Get_a_Data_Item(Data_Item_Set(Query)) 從查詢 Query 的資料項集合中，取出一個資料項 Get_a_Data_Item_ID(REPORTinvalidation) 從驗證報告 REPORTinvalidation中，取出一個資料項識別碼
Queuequery 查詢佇列，儲存尚未執行完成的查詢
Queuelisten 監聽佇列
Queryarrival 系統中剛到達的查詢 Data_Itemarrival 系統中剛到達的資料項 ID(Data_Item) 資料項 Data_Item 的識別碼
在本方法中演算法所用到的符號如下：我們將以 VSnew代表暫存記憶體中的 新版本集合，VScurrent代表暫存記憶體中的目前本集合，VSinvalid 代表暫存記憶體 中的失效版本集合。Data_Item_Set(Query)代表所查詢 Query 的資料項集合，
Get_a_Data_Item(Data_Item_Set(Query))代表自查詢到的資料項集合中，取出一個 資 料 項 的 識 別 碼 ， Get_a_Data_Item(REPORTinvalidation) 代 表 自 驗 證 報 告 REPORTinvalidation 中取出一個資料項的識別碼，QUEUEquery 代表查詢佇列，用來 存放尚未完成的查詢，QUEUElisten代表監聽佇列，用來存放需要監聽的資料項的 識別碼，QUEUEEarrival代表系統中剛到達的查詢，Data_Itemarrival 代表系統中剛 到達的資料項，ID(Data_Item)代表資料項 Data_Item 的識別碼。
4.2.1. 查詢到達事件
處理本事件的演算法如圖 4-2，而其處理流程如下：
1. 當行動客戶端收到使用者提出查詢 Queryarrival要求時，首先會判斷暫存記憶 體中的版本集合(表示為 VSnew∪VScurrent∪VSinvalid)是否為空集合，如果為空集 合則執行步驟 4，否則進行下一個步驟。
2. 檢查新版本集合與目前版本集合共同組成的集合中(表示為 VSnew∪VScurren)是 否含有此次所需查詢的資料項(表示為 Data_Item_Set(Queryarrival))，如果是的 話則回答並結束此次查詢，否則進行下一個步驟。
3. 檢查目前版本集合與失效版本集合共同組成的集合(表示為 VScurrent∪VSinvalid) 中是否有此次所需查詢的資料項，如果是的話則回答並結束此次查詢，並告 知使用者此次查詢結果有可能不在互斥一致性下，反之則代表此次查詢所要 求的資料項並未完全暫存於暫存記憶體中，接著進行下一個步驟。
4. 將此查詢所要求的資料項卻未存在行動客戶端暫存記憶體的資料項加入監 聽佇列(表示為 Queuelisten)，也將此次查詢 Queryarrival加入查詢佇列(表示為 Queuequery)中，並結束此事件的執行。
EVENT Query_Arrival GIVEN Queryarrival
//檢查暫存記憶體是否為空集合
IF (VScurrent ∪ VSnewt ∪ VSinvalid) IS EMPTY
DO UNTIL Data_Item_Set(Queryarrival) IS EMPTY
LET Data_Item = Get_a_Data_Item(Data_Item_Set(Queryarrival));
ADD Data_Item TO Queuelisten; LOOP
ADD Queryarrival TO Queuequery
ELSE
//檢查此次查詢的資料項是否皆在 VScurrent ∪ VSnew IF Data_Item_Set(Queryarrival) ⊂ { VScurrent ∪ VSnew }
RETURN THE RESULT OF THIS QUERY;
END OF THIS ROUTINE；
ENDIF
//檢查此次查詢的資料項是否皆在 VScurrent ∪VSinvalid
IF Data_Item_Set(Queryarrival) ⊂ { VScurrent ∪ VSinvalid } RETURN THE RESULT OF THIS QUERY
AND NOTIFY USER THIS RESULT MAY BE NOT CURRENT;
END OF THIS ROUTINE；
ENDIF
//將未在暫存記憶體中的資料項加入監聽佇列並將查詢加到查詢佇列中 DO UNTIL Data_Item_Set(Queryarrival) IS EMPTY
LET Data_Item = Get_a_Data_Item(Data_Item_Set(Queryarrival));
//檢查資料項是否存在於記憶體中
IF Data_Item ∉ { VScurrent ∪ VSnew }AND Data_Item ∉ VSinvalid ADD Data_Item TO Queuelisten;
ENDIF LOOP
ADD Queryarrival TO Queuequery； ENDIF
END
圖 4-2 處理查詢到達事件的演算法
4.2.2. 驗證報告到達
處理本事件的演算法如圖 4-3，而其處理流程如下：
1. 當行動客戶端在廣播週期將要到達時，首先會將新版本集合中的資料項移至 目前版本集合中，等完成此項工作後便進行下一個步驟。
2. 行動客戶端在接收驗證報告(表示為 Reportinvalidation)後，開始並針對目前版本 集合做驗證資料項的動作，把驗證出為失效的資料項從目前版本集合中移至 失效版本集合中。
EVENT Invalidation_Report_Arrival GIVEN Reportinvalidation
DO UNTIL VSnew IS EMPTY
LET Data_Item = Get_a_Data_Item(VSnew);
REMOVE Data_Item FROM VSnew
ADD Data_Item TO VScurrent; LOOP
DO UNTIL Reportinvalidation is EMPTY
LET ID = Get_a_data_Item_ID(Reportinvalidation );
LET Data_Item = ID_To_Data_Item(ID);
IF Data_Item∈VScurrent
REMOVE Data_Item FROM VScurrent; ADD ID(Data_Item) TO Queuelisten; ENDIF
LOOP END
圖 4-3 處理驗證報告到達事件的演算法
4.2.3. 監聽資料到達
處理本事件的演算法如圖 4-4。而其處理流程如下：
1. 當行動客戶端在接收到所監聽的資料項(表示為 Data_Itemarrival)時，首先將資 料項識別碼自監聽佇列中刪除，並檢查此資料項是否為失效版本集合中的失 效資料項(檢查 Data_Itemarrival ∈ VSinvalid)，如果檢查出是的話則將失效資料 項自失效版本集合中刪除，再將剛接收到的資料項 Data_Itemarrival加入新版 本集合中，反之則直接將接收到的資料項加入新版本集合中，接著進行下一 步驟。
2. 檢查查詢佇列中 Queuequery的查詢，確認是否已有查詢所要求的資料項皆完 全存在於新版本集合與目前版本集合共同組成的集合(VSnew∪VScurren)中，如 果是的話則回答並結束此次查詢，同時將此查詢自查詢佇列中刪除。
EVENT Listen_Data_Item_Arrival GIVEN Data_Itemarrival
REMOVE Data_Itemarrival FROM Queuelisten; IF Data_Itemarrival ∈ VSinvalid
REMOVE Data_Itemarrival FROM VSinvalid; ELSE
Data_Item_Replacement_Routine();
ENDIF
ADD Data_Itemarrival TO VSnew
FOR EACH Queue ∈ Queuequery
IF Data_Item_Set(Query) ⊂ { VScurrent ∪ VSnew } RETURN THE RESULT OF THIS QUERY;
ENDIF LOOP END
圖 4-4 處理監聽到達事件的演算法
以上就是我們透過查詢到達、驗證報告到達、監聽資料到達三個事件來維持 客戶端暫存資料一致性的方式，由以上三個事件可看出資料項在三個版本集合下 的移動方式。假設行動客戶端的暫存記憶體一開始並無任何資料項，當廣播週期 到達後，監聽程式便根據監聽佇列中的內容將所需資料項透過廣播通道擷取下 來，並將所擷取資料項放置於新版本集合中，此時行動客戶端的資料便和資料庫 伺服端達到一致性狀態。當下個廣播週期到達後，行動客戶端首先會將新版本集 合中的資料項移到目前版本集合中，再驗證目前版本集合中資料的正確性，將已 失效的資料項移至失效版本集合中，等到所監聽的資料項到達時便接收並加入新 本集合中，如此ㄧ來，行動客戶端暫存記憶體中新版本集合與目前版本集合所組 成的共同集中的資料項，便與本廣播週期中的資料庫伺服端狀態為一致性狀態，
而目前版本集合與失效版本集合所組成的共同集中的資料項，便與上個廣播週期 中的資料庫伺服端狀態為一致性狀態。
在過往的研究中[4,11,15]，在行動客戶端提出查詢後，並不在暫存記憶體中 搜尋所需的資料項，直接把此次查詢要求加入查詢佇列、並將此次查詢在暫存記 憶體中所欠缺的資料項加入監聽佇列，等到驗證報告到達並驗證暫存記憶體中的 資料後，才對查詢做處理。在本研究方法中為了達到放鬆互斥一致性原則下，當 查詢到達時，允許行動客戶端直接搜尋暫存記憶體中的資料項是否符合此次查
詢，首先，查詢處理程式先至新版本集合及目前版本集合中的共同集合中做搜 尋，若此次查詢的資料項皆在此共同集合中，即代表此次查詢結果為目前一致性 的狀態，如果無法在此共同集合中結束查詢，再到目前版本集合中及失效版本集 合的共同集合中做搜尋，若此次查詢的資料項皆在此共同集合中，代表此次查詢 結果處於過去某一次一致性狀態下。若查詢到達時並無法在暫存記憶體中搜尋到 資料項，便將此次查詢存放於查詢佇列中，等待下個廣播週期驗證暫存資料項的 正確性並擷取查詢所需資料項後，再對查詢做處理，此時的查詢結果則符合互斥 一致性的狀態。