--------------------------------------------------- Return-Path: rgrimm@cs.washington.edu Received: from june.cs.washington.edu (june.cs.washington.edu [128.95.2.4]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id XAA23878 for ; Wed, 12 Feb 1997 23:37:48 -0800 Received: from [128.95.8.128] (h128.dyn.cs.washington.edu [128.95.8.128]) by june.cs.washington.edu (8.8.5+CS/7.2ju) with SMTP id XAA11242 for ; Wed, 12 Feb 1997 23:37:46 -0800 X-Sender: rgrimm@june.cs.washington.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Feb 1997 23:35:15 -0800 To: bershad@cs From: rgrimm@cs.washington.edu (Robert Grimm) Subject: Quicksilver-RecoveryManagement 552-reading summary Haskin et al. describe recovery management in Quicksilver. Realizing that protocol-level consistency and atomicity guarantees (or the lack thereof in connectionless protocols) are not sufficient for many applications, Quicksilver uses transactions to provide the necessary end-to-end semantics. Quicksilver provides three different types of transactions (to handle stateless, volatile, and recoverable services), three different one-phase and one two-phase commit protocols and a low-level log-server that allows applications to implement their own recovery policies. The paper describes each protocol in detail and provides a comprehensive performance analysis. In my opinion, the paper is much more successful in describing the Quicksilver architecture than Schmuck et al. The detailed description of the individual types of transactions and commit protocols shows that the designers paid careful attention to performance issues (e.g., the hierarchical structure of several transaction managers to avoid excess communication), separated mechanism from policy where necessary (i.e., the log manager allows applications to implement their own recovery policies) and went to considerable effort to ensure that different applications can use different types of transactions with the appropriate consistency and atomicity guarantees (i.e., the different types of transactions and commit protocols). The performance evaluation provides a good overview of the costs associated with the different types of transactions and commit protocols. However, I am still not convinced that the space of transaction semantics provided by Quicksilver is entirely appropriate. Going back to the locking problems described by Schmuck et al., it seems that applications have good choices as to what atomicity and consistency guarantees they require, but that the isolation guarantees of Quicksilver transactions are too strong. The result is a mismatch between application requirements and the basic communication mechanism. It is here, that I apply the end-to-end argument (though, it is a somewhat reversed end-to-end argument): The isolation properties of transactions in Quicksilver are too strong; but, since they are part of the end-to-end communication system, applications can not avoid them. Applications thus have to go through some pains (e.g., by using transactions at a finer granularity than desired) to provide the desired functionality (and some applications may simply be unable to provide the desired functionality). It thus seems that Quicksilver would win if isolation was another parameter in the space of protocol options. --------------------------------------------------- Return-Path: tian@wally Received: from wally.cs.washington.edu (wally.cs.washington.edu [128.95.2.122]) by whistler.cs.washington.edu (8.8.3/7.2ws+) with ESMTP id XAA20568 for ; Mon, 17 Feb 1997 23:57:39 -0800 Received: (tian@localhost) by wally.cs.washington.edu (8.8.3+CSE/7.2ws+) id XAA15127; Mon, 17 Feb 1997 23:57:38 -0800 (PST) Date: Mon, 17 Feb 1997 23:57:38 -0800 (PST) From: Tian Lim To: Brian Bershad Subject: Quicksilver-RecoveryManagement 552-reading summary Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Recovery Management in QuickSilver This paper gives a fairly detailed overview of the Quicksilver architecture and protocols. They motivate the use of transactions in a distributed system by presenting it as a unified mechanism for distributed resource management, in addition to the other desirable ACID properties. They recognize that the primary problem with distributed systems is the large amount of state maintained by servers on the behalf of clients. In addition to difficulties in maintaining correctness, there are also complex new failure modes that the application and services programmer must deal with. These can all be managed more easily through the use of transactions. For instance, membership in a transaction is handled implictly via IPC, and all participants will be notified of the result of the transaction in order to do the right thing. The end to end argument rejects the implementation of such a high level abstraction. The design of the protocol variants reflect this. By exposing some low level mechanisms (such as logging) and providing alternative transaction semantics (fast one phase commits etc.), the designers show that a wide range of applications, from performance-oriented systems to replicated systems can make use of transactions without unduly heavyweight semantics. There are still some concerns. It is not clear how effective and general their modified protocols are. Their main applications are the distributed file system, nameserver and window manager. All of these examples are well motivated and demonstrate effective use of the transaction mechanisms, but little is said of more general applications and how well they will utilize the variants, or if the variants are flexible enough to support more finer grained parallelism.