Resolver Development

Compared to programming a transaction, the programming of an application-specific resolver can be a demanding task. We conducted a number of case studies to write resolvers for some non- trivial and commonly-used Unix applications. Our purpose was to evaluate how well the task of programming resolvers was supported. In this section, we first present two resolver examples, and then summarize our resolver programming experience with some general observations. 9.4.3.1 Case Studies

A Smart Resolver for Make We developed a resolver formakebased on the source code of the CMU Mach make to demonstrate that our application-specific resolver paradigm can indeed work for practical and sophisticated Unix applications. The main objective of this exercise is to investigate how application semantics can be employed to resolve conflicts more efficiently.

When a make transaction fails to certify, it means that some of the objects accessed by the transaction have been updated on the servers. As discussed in Chapter 3, an automatic re-execution of the same transaction under the original environment is guaranteed to restore data consistency as required by the semantics of make. But, re-execution is often wasteful, because it throws away local results even when most of them can be reused. For example,

The window image in this figure is taken from the console of elgar, a desktop Coda client. The

Loginwindow displays the main actions on elgar: disconnecting it from the servers, executing amaketransaction that compiles acfs.ofile and links it with a librarylibutil.aand other libraries to create thecfsbinary file. Before elgar reconnects to the servers, another connected clientCOPLANDinstalls a new version of librarylibutil.a, as shown by the COPLAND telnet window. Upon reconnection, the transaction system on elgar fails to certify themaketransaction and automatically invokes the smart-make resolver. The IOT Monitor window shows the resolution actions where the local result ofcfs.ois reused and the new version oflibutil.a

is linked to create an up-to-date version ofcfs.

suppose a disconnectedmaketransaction compiles dozens of object files and builds a Venus binary. However, one of the libraries linked in was updated on the servers during the discon- nection. Upon reconnection, we can reuse those locally compiled object files and re-link them with the new version of the library to produce an up-to-date Venus binary. This can avoid the unnecessary recompilations of the objects that would have been performed by automatic re-execution.

We developed a resolver for make called smart-make. Its first part is programmed based on both the originalmakesource code and the resolution object view provided by IOT’s dual-replica conflict representation. It extends the basicmake dependency checking with the inspection of the local and global replicas for objects that are in conflict. This enables it to identify those local objects that were updated by the original make transaction and are still compatible (as required by themakedependency semantics) with the current global state. For each maketarget, the resolver first obtains its local replica, and then tracks the dependencies defined in the correspondingmakefile(s)to find out all the objects that the target depends on. If any of them has different local and global replicas, the target is re-made. Otherwise, the local replica of the target can be reused and is copied onto the corresponding global replica.

The second part of smart-makeuses the ASR programming library routines to set the global object view so that only the global state is visible to the resolver. Note that the visible global state after the first part may contain the reusable local results that just have been copied into the relevant global replicas. The resolver simply calls internalmakefunctions to re-make the remaining targets and restore the original object view. When the resolver exits, the IOT system will take over and automatically commit the new results to the servers and discard all the previous local results. A complete example that illustrates how thesmart-makeprogram can efficiently resolve amaketransaction is shown in Figure 9.13.

An Interactive Resolver for RCS Checkout For some Unix applications, there are often different alternatives to resolve a read/write conflict and the best strategy for an application- specific resolver is to interact with the user. Because such interactive resolvers need to display messages to the users and read input from them, they have to manage input/output as explained in Chapter 6. Figure 9.14 illustrates an interactive resolver we have developed for the RCS checkout command (rcsco). The resolver was developed using tcl/tk and written as a

wishscript.

9.4.3.2 General Observations

Programming a resolver can be quite difficult, particularly for complicated applications. Work- ing knowledge of the source code of the original application is a must. We spent a significant amount of time in studying themakesource code during the development of thesmart-make

The window image in this figure demonstrates an interactive resolver for rcsco. The target transaction being resolved is anrcscocommand that checked out an old version ofiot.hduring disconnection, which was later updated on the servers. The resolver is automatically invoked after the read/write conflict is detected. It displays the content of both the local and global versions ofiot.hand the difference between them. It also provides the user three resolution options by simply clicking the corresponding button.

Figure 9.14: An Example of A Resolver for RCS Checkout

resolver. In general, the original author(s) or the site maintainer(s) of an application are the best candidates for writing the corresponding resolver.

The IOT resolution model is not easily understood at first sight. It usually requires some concrete examples for a novice IOT programmer to grasp the essence of the model and be able to code resolvers. The difficulty usually lies in figuring out what is detected by the IOT mechanism and what the file level conflict means to the application at a semantic level. However, once the user is able to code a simple resolver, it is not as difficult to apply the same principles to more complicated cases.