6.2.3.1 Transactional Encapsulation
The automatic execution of a resolver for the target transactionTis performed within the scope of a special isolation-only transaction denotedres(T). The transaction system manipulates the internal representation ofres(T)so that it implicitly inserts thebegin iotandend iot
calls before the execand after the exit of the resolution process respectively. The entire execution ofres(T)is performed in a manner similar to a normal connected transaction. All the file access operations performed by the resolver are recorded in the readset and writeset of
res(T). In addition, mutation operations are performed locally and logged in the CML of the corresponding volumes.
6.2.3.2 Handling Failures
The only differences between the execution of res(T)and a regular connected transaction are the way in which failures are handled.
Validation Failure The consistency of an automatic resolution session for target transactionT
the response to OCC validation failure is automatic abortion and re-execution. However, this approach is not suitable forres(T)because the automatic resolver execution holds exclusive control over many client resources and automatically re-executing res(T) could deny the users needed services for a long period of time. For simplicity, our design aborts the result of
res(T)as well as the whole resolution session and conservatively forces the users to manually repairTby transiting it into the to-be-repaired state.
Abnormal Termination For a regular connected transaction, the termination of its execution means the completion of the transaction regardless of theexitstatus. With respect tores(T), however, any abnormal termination such as crashes due to segmentation fault, etc., must be treated as a failure and the resolution session must be aborted. Thus, it is very important for the resolver to carefully check for abnormal conditions such as getting an ETIMEDOUTerror code when opening a Coda file, and exit with non-zero status appropriately.
6.2.3.3 Managing Interactive I/O
The Challenge of Interactive I/O Unix applications often employ interactive I/O to inform the users about the status of the execution and request feedback for further computation. Previous research has demonstrated that including interactive I/O into the transaction model is a very difficult problem and there is no general solution [54]. Handling interactive I/O during automatic resolution is even more of a challenge because the I/O environment is often different from when the target transaction was originally executed. The user who executed the target transaction may not even be logged in on the client machine while the resolution is going on. In general, it is very difficult for the transaction system to automatically select the proper devices for the resolver execution to conveniently interact with the users. The current IOT implementation only provides limited support for the standard input/output operations performed by the resolver so that automatic conflict resolution for typical Unix applications can be performed. Tackling the complete problem of interactive I/O in automated conflict resolution is beyond the scope of this dissertation.
Supporting Automatic Transaction Re-execution When the resolver is the target transac- tion itself, standard I/O during resolution is performed in the same way as during the original transaction execution. Our strategy of supporting standard output is to maintain resolution transparency while preserving output messages. The specific mechanism binds the standard output of the re-execution process to a special disk file so that a complete history of standard output during the resolution is recorded. The output messages are not visible to the users unless specifically requested. A monitoring tool is provided to continuously display the growing content of the special file for any user who wishes to closely follow the resolution process.
Standard input during automatic re-execution is much harder to deal with and there is no satisfactory solution. Although it is possible for the transaction system to create a designated window or pseudo-terminal for the users to type input data, resolution transparency has to be sacrificed because standard output messages must be made visible to prompt for user input. The current IOT implementation does not provide special support for standard input other than binding it to the terminal where the current Venus incarnation was initiated. Thus, the automatic re-execution resolution option should be used only for applications that do not need interactive input such as makeand gcc. Fortunately, this is not a severe limitation in practice because Unix applications for which automatic re-execution is likely to be selected as the resolution option typically read input from files instead of interactively from the users.
Supporting Automatic ASR Execution The default support for interactive I/O during the au- tomatic execution of an application-specific resolver is the same as for transaction re-execution. However, an application-specific resolver does not have to perform interactive I/O in the same way as its corresponding transaction. It has the complete freedom to manage interactive I/O in its own way. For example, the resolver can take advantage of existing facilities such as
tcl/tk[52] to dynamically create windows for displaying messages to the users and reading input data from them. An actual example using this approach will be presented in Chapter 9. In summary, the transaction system only provides support for resolvers that perform standard output but not standard input. If reading interactive input is a necessity for a resolver, it must manage its own standard input and output together.
6.2.3.4 Local Concurrency Control
Strict local concurrency control is imposed to protect a resolution session from being interfered with by the execution of other ongoing transactions. New isolation-only transactions are not allowed to start until an ongoing resolution session is completed. Furthermore, all the cached volumes are write-locked by the resolution process.