【正文】 ccessed by the client applications. Fig. 1 shows its architecture. The testbed was created to allow experiments with 3 functionally parable OTS SQL servers, Oracle , MS SQL , Interbase . The servers can run under any operating system for which there are versions of the products used。即永遠(yuǎn)的客戶，也是唯一的，收到多個“鎖請求超時超出”不知何故被刪除，直到非碰巧的客戶端阻塞鏈，如超時各自的查詢，這可能需要很長時間。值得指出，我們讓包裝操作 MSSQL 特定的的鎖定超時不干擾查詢超時設(shè)置（不同的機(jī)制，可與任何 SQL 服務(wù)器的客戶端應(yīng)用程序）。它的默認(rèn)值是 0，即阻塞的線程將等待永遠(yuǎn)為所需要的鎖。我們以 Microsoft SQL 服務(wù)器為 例，發(fā)現(xiàn)，當(dāng)客戶數(shù)量超過 20 人次，創(chuàng)建 SQL 服務(wù)器競爭線程之間客戶服務(wù)共享鎖停止正常工作。 瓶頸模式，一個非常嚴(yán)格的客戶端訪問服務(wù)器的訂單總額，與客戶之間的任何并發(fā)。測試平臺配置參數(shù)是允許改變的，如 ： 客戶數(shù)量和每一個實驗中提交的查詢 。它允許一個客戶端運行各種應(yīng)用程序，同時針對不同的 SQL 服務(wù)器使用入門級的SQL92 語言子集。這個副本一致性的問題審議了很長一段時間，仍然解決了一般數(shù)據(jù)庫服務(wù)器關(guān)于保護(hù)性包裝，我們提出的保護(hù)理念 172。 SQL 服務(wù)器的進(jìn)一步改進(jìn)可靠 性，似乎唯一可能的是通過設(shè)計多樣性容錯。容錯可采取多種形式。 我們所使用的“組件”一詞在通用工程意義稱為組裝，它可形成一個系統(tǒng)，并且是在他們自己的權(quán)利系統(tǒng)基礎(chǔ)上建立的。然后，我們討論如何結(jié)合成一個多元化的模塊化冗余配置（ N版本軟件或 N 種自檢軟件）成各種各樣的服務(wù) 器。本文中，我們側(cè)重于可靠性概率 LEMS、 OTS的組件構(gòu)成的系統(tǒng)集成介紹，他們的文檔通常僅限于定義良好的接口，簡單的示例應(yīng)用程序演示了如何可以在一個系統(tǒng)集成的組件。但是源代碼是可用的，可以利用它的規(guī)模和復(fù)雜特性。兩個或兩個甚至更多的在職培訓(xùn)組件（其中有些可能是免費的）采購成本遠(yuǎn)遠(yuǎn)比自己開發(fā)的少很多。我們正在運行的實驗，以確定通過容錯來實現(xiàn)可靠性收益。之間的在職培訓(xùn)計劃的組 成部分和其余 危險通信攔截系統(tǒng)，從而保護(hù)了對方的故障。創(chuàng)建測試平臺，允 許 3 個功能相媲美的 SQL 服務(wù)器， Oracle ， MS ， 進(jìn)行實驗。存在一個“模板編輯器”工具延長交易集和概率分布，這樣就可以嘗試使用更廣泛服務(wù)器上的負(fù)載 。 Write Bottleneck 模 式，在包裝允許的情況下，目前的觀測（即只讀）交易被發(fā)送到服務(wù)器，但任意數(shù)量的并發(fā)之間沒有修改交易（其中包含至少在 INSERT，DELETE 或 UPDATE聲明）。一個解決的是應(yīng)用程序管理員 或 檢測情況，并介入殺害的線程持有的所有鎖，但仍然在“睡眠”狀態(tài)（即是在封鎖鏈 的根線程）。在一些回滾的交易成本中，該解決方案是不足以解決“壞堵”現(xiàn)象。沒有 BUG ＃ 56013 ，查詢超時長可以共同存在很短，沒有任何中止LOCK_TIMEOUT。V. We report our experience with an experimental setup we have developed with offtheshelf SQL database servers. First, we describe the use of a protective wrapper to mask the effects of a bug in one of the servers, without depending on an adequate fix from the vendors. We then discuss how to bine the diverse offtheshelf servers into a diverse modular redundant configuration (Nversion software or Nselfchecking software). A wrapper guarantees the consistency between the diverse replicas of the database, serving multiple clients, by restricting the concurrency between the client transactions We thus show that diverse modular redundancy with protective wrapping is a viable way of achieving faulttolerance with even plex offtheshelf ponents, like database servers. 1 Introduction The audience of this conference is well aware of the pros and cons of using offtheshelf (OTS) software ponents1. In this paper we focus on the dependability problems that OTS ponents pose to system integrators: their documentation is usually limited to well defined interfaces, and simple example applications demonstrating how the ponents can be integrated in a system. Component vendors rarely provide information about the quality and Vamp。 ? the “demand profiles” of the clients, a probability distribution defined on the set of queries used. The query types and parameter values are chosen by the testbed, according to userset probability distributions. A “Template Editor” tool exists for extending the set of transactions and setting the probability distributions, so that one can experiment with a wide range of loads on the servers。 or even fullfledged replication with diverse versions of the ponents. Such “diverse modular redundancy” seems desirable because it offers endtoend protection via a fairly simple architecture, and protection against the identical faults that would be present in replicas within a nondiverse modularredundant system. The cost of procuring two or even more OTS ponents (some of which may be free) would still be far less than that of developing one’s own. All these design solutions are well known. The questions, for the developers of a system using OTS ponents, are about the dependability gains, implementation difficulties and extra costs that they would bring for that s pecific system. To study these issues, we have selected a category of widely used, fairly plex OTS ponents: SQL database servers. Faults in the currently available SQL servers are mon. For evidence one can just look at the long list of bug fixes s upplied by the vendors with every new release of their products. Further reliability improvement of SQL servers seems only possible if faulttolerance through design diversity is employed [3