Conflict Resolution Options

The fundamental difference between 1SR for connected transactions and G1SR/GC for discon- nected transactions is that the former is strictly enforced at transaction execution time while

the latter can only be validated for pending transactions when communication with the relevant servers is restored. Hence, as an integral part of consistency maintenance for disconnected transactions, the IOT consistency model must specify what the system will do if validation fails. Our design provides the following four conflict resolution options to assist transaction users and programmers to restore consistency.

Automatic Re-execution When a disconnected transaction fails validation, one way to restore data consistency is to re-execute the transaction automatically by accessing up-to-date data from the servers. Consider Example 7 once again. If Joe wants to make sure that thecfsexecutable built on the disconnected laptop is compatible with the latest system release, he can choose GC as the consistency criterion and automatic re-execution as the resolution option for TJoe. WhenTJoeis invalidated at re-connection time, the IOT system will automatically rerun make to build an up-to-date version ofcfsby linking in the newlibutil.a.

The main advantage of this option is that it can be performed automatically without putting additional demand on transaction programmers and users. It is particularly useful for a class of Unix applications that primarily act as translators, reading input data from a set of files and generating output into a different set of files, such as make, cc, and latex. The ability to restore consistency automatically and application independently provides much- desired transparency in the resolution process, making automatic re-execution the workhorse of conflict resolution in our target application domains.

Automatic Abort The second conflict resolution option is to automatically abort an inval- idated transaction by throwing away its local computation result. It is similar to the rollback mechanism of the traditional transaction recovery. Like the first option, it is also automatic and application independent. But it is only applicable in a few situations where getting rid of the local results is more appropriate than making forward progress. For example, suppose that a transaction runs every midnight traversing a file system subtree, computing statistics such as height and average branch factor of the subtree, and appending a new record to a log file accumulating the statistics. If such a transaction is invalidated, it means that the statistics it computed were based on a stale version of the subtree cached on the client. Automatic abort is an appropriate resolution choice for this transaction because it prevents an incorrect record from being appended to the log file.

Application-Specific Resolver (ASR) Our third option is to automatically invoke a user- supplied application-specific resolver (ASR) [29, 32, 68]. At the start of execution, a transaction can specify a user program that will be automatically invoked for conflict resolution if this transaction is later invalidated. ASR is a unique feature of the IOT model and is the key

mechanism that allows integration of application semantic knowledge into the basic transaction operations.

First, the ASR mechanism enables automatic compensation of disconnected transactions containing external side effects. Consider a schedule maintenance program used by a business executive to automatically check her schedule files and send out fax messages to arrange business activities. Suppose that she takes her portable computer on a trip. While disconnected, she runs the program as a transaction to enter a few new appointments and sends out fax messages to notify relevant people about an upcoming meeting. However, her secretary adds several conflicting activities into the server copies of the schedule files during her absence. When the executive reconnects her portable computer to the servers, the transaction system can automatically execute a resolver program that checks for conflicting appointments and sends out new fax messages if necessary.

Second, the ASR mechanism allows application semantics to be utilized to resolve conflicts more effectively. Let us revisit Example 7 one more time. Suppose Joe ran a large make

transaction to build a new kernel on the laptop. However, one of the linked libraries was updated during the disconnection. Using the automatic re-execution option can certainly resolve the conflict, but it would throw away all the local compilation results and rerun the long transaction all over again. Instead, we can program a resolver that takes advantage of the semantic knowledge ofmaketo avoid unnecessary recompilations. In this case, the resolver can simply keep most of the local compilation results and re-link them with the new library.

Third, the ASR option enables application-specific consistency validation. By default, consistency validation is performed solely on the basis of syntactic information of file access operations. But this is a conservative approach. An invalidated transaction does not necessarily mean that the data involved are actually inconsistent. The ASR mechanism provides the resolver an opportunity to refine the check for data inconsistency using application semantics. Consider the following example where machine reservations for two computer clusters A and B are stored in filesreserveAandreserveB. A simple consistency requirement for both files is that the same user can not reserve machines at both clusters. To reserve a slot for user Joe in cluster A, a transactionTJoeis executed to add a new record inreserveAafter making sure that reserveB does not contain a conflicting record. Suppose that TJoe is a disconnected transaction due to a partition failure. Meanwhile, filereserveBis updated on the servers to add a reservation record for user Mary. Even though transaction TJoe will be invalidated, its local result is consistent with the new server state. The unnecessary resolution forTJoecan be avoided by using a resolver that is capable of recognizing the consistency of reserveAand

reserveBbased on application semantics and retaining the transaction’s local result.

In summary, the application-specific conflict resolution paradigm is a centerpiece of the IOT model that integrates different aspects of the model into a coherent design. First, our need for practical usability and Unix compatibility demands transaction validation to be computa- tionally efficient and capable of screening out non-1UE behaviors. Such requirements entail the

selection of a restrictive consistency criterion such as GC. However, ASR supplements GC by integrating application semantics in consistency validation. As a result, consistency validation is well supported by two complementary mechanisms: efficient GC validation for the common cases and application-specific validation for the subtle cases. Second, disconnected operation departs from the traditional optimistic computation models by exposing tentative results to external viewers. ASR addresses the vulnerability of potentially unrecoverable side effects by serving as a generic dispatcher for automatic compensating actions.

Manual Repair As a last resort, a transaction can choose to be manually resolved when invalidated. We use the term repair to refer to the manual conflict resolution process. It also serves as the fallback option when other options fail. If an abnormal condition or an erratic resolver results in failed automatic resolution of an invalidated transaction, the users will be requested to manually repair the transaction. The IOT mechanism provides a repair tool to assist the users to inspect the local and global states of the relevant objects and to create the resolution result.

Transaction Consistency Specification Before execution starts, a transaction must specify which criterion (G1SR or GC) to use for consistency validation when disconnected and which resolution option to use for conflict resolution when invalidated. If the resolution option is ASR, the user must also provide information about the resolver. We call such information about the selection of consistency criterion and resolution option the transaction consistency

specification. It can be supplied to the transaction system through the arguments of both

begin iotandend iotcalls. 3.3.4.4 Implementation Restriction

We decided to implement only the GC consistency validation in this research because the im- plementation complexity of G1SR far outweighs its practical value for the following reasons. First, in the implementation framework proposed by Davidson [9], validating G1SR for discon- nected transactions requires the construction of a global graph data structure, which is likely to hurt system availability and scalability. Furthermore, it requires the servers to maintain a complete history of committed transactions from the beginning of a disconnection. Given the fact that a portable client can be disconnected for a long period of time, the server space cost for recording transaction histories can be prohibitive.

Second, although G1SR is a much more general consistency framework than GC and less susceptible to false-negative validation, the combination of GC and application-specific revali- dation capability can adequately offset the loss of G1SR’s generality. Our experience suggests that GC is better suited for the consistency needs of using disconnected operation for mobile file

accesses. Moreover, validating GC for disconnected transactions can be implemented much more efficiently with minimum server resource cost, which is very important for preserving overall system scalability.

Finally, although an implementation of G1SR is outside the scope of this dissertation, the current IOT design and implementation are fully compatible with future support for it.