【導(dǎo)讀】經(jīng)驗，就拿現(xiàn)成SQL數(shù)據(jù)庫服務(wù)器來說。首先，我們描述了一個防護(hù)性包裝來掩蓋。通過包裝保證了數(shù)據(jù)庫不同副本之間的一致性，并為多個CLI. 余是可行的，復(fù)雜的甚至都可以實現(xiàn)容錯現(xiàn)成組件。對于用的軟件元件在會議上各方各持己見。本文中，我們側(cè)重于可靠。的接口，簡單的示例應(yīng)用程序演示了如何可以在一個系統(tǒng)集成的組件。這將創(chuàng)建任何嚴(yán)格的可靠性要求的集。至少在非安全關(guān)鍵CAL行業(yè)，供應(yīng)商往往把不能接受甚至反感的現(xiàn)成組件。這也是目前系統(tǒng)集成商所面臨的。且是在他們自己的權(quán)利系統(tǒng)基礎(chǔ)上建立的?！敖M件”可能是任何一件事，在軟件庫中。用于組裝應(yīng)用，并可以作為獨立系統(tǒng)使用的應(yīng)用程序。可能會拒絕優(yōu)勢通常采取授予時的源代碼是。通常情況下，不能改善OTS的組件，執(zhí)行額外的V＆V活動是。其交易影響力是可想而知的，但這種可能性并不能幫助當(dāng)下的系統(tǒng)集成商。生嚴(yán)重后果，甚至影響組件的狀態(tài)恢復(fù)全面復(fù)制。截系統(tǒng)，從而保護(hù)了對方的故障。

　　

【正文】 nd bee more frequent as this number increased. As we later found out, Microsoft reported the problem as due to a fault of the SQL server (Bug 56013, [10]). A workaround is for the administrator or for an application to detect the situation and intervene by killing the thread that holds all the LOCKs but remains in a “sleeping” state (. is in the root of the chain of blocked threads). However, manual intervention by the administrator is costly and may still allow large delays before being undertaken. Handling the problem explicitly in the client applications is only satisfactory if all clients handle the situation properly. We have found another fully automated solution, which is relatively painless and can be incorporated in a wrapper, without changes to the legacy clients. It utilises a parameter, specific for MSSQL, LOCK_TIMEOUT, which can be explicitly set for each query. Its default value is 0, . the blocked thread would wait for the needed lock forever. Setting it to nonzero value (we used 10 seconds) would make the server raise an exception “Lock request timeout period exceeded” when the set lock timeout expires. Now the client instead of waiting forever will get the exception and can roll the transaction back, while the locks are passed on to other clients. This solution is sufficient to resolve the occurrences of “bad blocking”, at the cost of some number of transactions being rolled back. It can be improved if we include in the wrapper an exception handler for LOCK_TIMEOUTs, which would gradually increase the LOCK_TIMEOUT period, or just repeat the transaction after rolling it back, and thus make the resolution of the “bad blocking” condition pletely transparent to the client. The cost of our simple solution, of course, is rolling back multiple transactions: not necessarily a high cost. The alternative killing the thread at the top of the blocking chain also has its cost. If a server thread is killed, the connection between the client and the server is lost and a new connection will have to be established, which is a more expensive operation than rolling back a few transactions. It is worth pointing out that our letting the wrapper manipulate the MSSQLspecific lock timeout does not interfere with the setting of the query timeout (a different mechanism, available to the client applications with any SQL server). A plex query may take very long to plete even under light load (. executing a plex query with subqueries) and, therefore, setting a large query timeout for all queries is reasonable. During the execution of a query, multiple LOCKS can be exchanged between the server threads which pete for access to a shared resource. Without bug 56013, long query timeouts can coexist with very short LOCK_TIMEOUT without any aborts. With this approach of implementing workarounds in wrappers, a user organisation can provide fault tolerance for bugs it discovers to be detrimental to the dependability of its installations, without waiting for the vendor to recognise the problem and issue a patch, which in any case may not pletely eliminate the undesired behaviour. When known problems are left open by the vendor, the system integrator has the only choice of either introducing a protective wrapper or building a workaround in the client applications. The latter option may well be more efficient, but it is more cumbersome to manage and implement correctly: the fix and any subsequent upgrade to it must be replicated in all the client applications. Note that in our example, if some clients did not properly use the LOCK_TIMEOUT defence, they could prevent the other, “wellbehaved” clients from accessing a shared resource forever. The wellbehaved clients would be the only ones to receive multiple “Lock request timeout period exceeded” exceptions until the blocking chain of non wellbehaved clients is removed somehow, . by timing out the respective queries, which may take long. In summary, implementing a fix in the wrapper reduces dependence on fixes by the vendor, and it seems always a better option than implementing it in the client applications, so long as feasible and the performance penalty incurred at runtime is acceptable.