As a fundamental component of the IOT consistency model, executing application-specific resolvers plays a key role in automatic conflict resolution. The viability of the application- specific resolution approach very much depends on how effectively the task of programming the resolver of a given target application can be accomplished. In order to make resolver pro- gramming as convenient as possible, the overall IOT design envisions a basic paradigm within which resolvers can be methodically developed for their corresponding target applications. Such a paradigm relies on a set of basic assumptions and is supported by the combination of various system components as well as specially designed facilities.
6.2.5.1 Programming Model
Basic Assumptions A fundamental assumption about resolver programming is that the de- velopers of a resolver must possess intimate knowledge about the internal details of the target application. The best candidates for writing a resolver are the target application’s original developers or installation site maintainers. For other programmers to develop a resolver for an existing application, they need to devote a significant amount of time to learn the internal mechanisms of the application. In our experience of writing resolvers for some typical Unix applications, much of the time is spent on studying the source code of the applications. The availability of the source code of a target application is essential to its resolver development.
Scope Isolation The incremental transaction propagation framework described in Chapter 4 is designed very much with the ease of resolver programming in mind. Invalidated transactions are resolved one at a time and the target transaction does not depend on any other live transactions when it is being resolved. In addition, the conflict representation mechanisms guarantee that the effect of other live transactions are not visible during the resolution. Therefore, the scope of inconsistency is greatly reduced since the resolver is relieved from the burden of considering complicated interactions between the target transaction and other live transactions. Logically, the resolver can regard the target transaction as the only one performed during the disconnected operation session. Hence, the task of a resolver is confined to investigating what the target transaction has done locally and what has been changed globally, determining the nature of inconsistency (if any), and performing the necessary actions to restore consistency.
Object View The design of the IOT conflict representation is directly aimed at supporting resolver programming. The in-place dual replica representation form allows the resolution result to be created via direct mutations on the relevant global replicas, eliminating the need for the resolver to use an extra workspace for resolution computations. The multiple view capabilities enable the resolver to utilize existing software tools and packages to resolve conflicts more effectively. Finally, the automatic elimination of the target transaction’s local result further reduces the resolver’s responsibilities.
Overall Structure For brevity, we useAPPandasr(APP)to denote the target application and its application-specific resolver respectively. A key design rationale in supporting resolver programming is to regard the task of a resolver as performing an alternative computation to achieve the original goal of the target transaction under a different system state. This enables
asr(APP) to be programmed with an overall structure that parallels that ofAPP. The main control flow ofAPPcan usually be decomposed into performing a sequence of specific tasks. For each task thatAPPwould attempt under the new conditions (reflected by the automatically restored original execution environment and the relevant global replicas), asr(APP) can perform the following actions.
It first checks whether the same task has already been performed by the target transaction and whether the local result is still compatible with the global state. If so, asr(APP) can reuse the local result by copying it into the relevant global replicas. Otherwise, asr(APP)
needs to perform the task using the up-to-date global replicas. If the original goal of the task needs to be adjusted due to changes in the global state,asr(APP)must come up with the new goal and perform the necessary computation to achieve it. Actions for compensating external side effects such as sendingemailare typically performed under such circumstances.
Several special resolution outcomes are worth mentioning. They are effectively degenerate cases. If the resolver execution reuses the entire local result of the target transaction, this is equivalent to a successful application-specific revalidation rescuing a syntactically invalidated transaction. If the resolution ends up performing every attempted task using the up-to-date global replicas, it is the same as resolution via automatic re-execution. If the global state is changed so much thatasr(APP)does not attempt any task, the target transaction is effectively aborted.
6.2.5.2 Programming Facilities
The main support for resolver programming is embodied in the incremental transaction propa- gation framework and the way conflicts are represented to the resolvers. There are two groups of library routines designed to provide information and convenience to the resolvers. The first group includes routines that allow the resolver to test which objects are read or written by the
target transaction. In addition, given the original pathname of a Coda object, there are routines that can translate it into the pathnames of the corresponding local and global replicas. The second group contains routines that enable the resolver to dynamically adjust object views. It also includes the preserve-operator that automatically reproduces the target transaction’s local result on the corresponding global replicas. The specific details of these routines are presented in the next chapter.
6.3
Manual Conflict Resolution
Manual conflict resolution is the safety net of the IOT conflict resolution mechanisms. It is used not only as the default choice of resolution options but also the fall-back mechanism when other alternatives fail. This section first discusses the main areas where a manual repair session differs from an automatic resolution session and then describes a repair tool provided for manually repairing invalidated transactions.