Visibility Maintenance

Visually notifying the users about inconsistent objects and preventing further access to them are only part of the general task of maintaining tentative computation results for live transactions. 5.2.3.1 Maintaining Live Transaction Results

The IOT-Venus has two main responsibilities in service mode. First, it must perform the regular cache management duties such as servicing cache misses and maintaining cache coherence. Second, it needs to maintain the tentative computation results produced by the live transactions so that they are visible in the client local state.

Object Asynchrony The essence of maintaining tentative computation results is to keep relevant cached objects asynchronous from their server state. Here, we use the terms asynchrony or asynchronous to refer to the situation where the client local state remains different from the server global state. In order to keep the result of a running or pending transaction visible in the client local state, the IOT-Venus must hold onto the cache copies of objects that are mutated

by the transaction without fetching their server replicas even if they are updated. Furthermore, cache copies of objects only read by those transactions need to remain in the client cache even though their server counterparts might have been changed. Thus, inconsistent objects are only a portion of the asynchronous objects that are made inaccessible to avoid spreading inconsistencies.

Visibility Control The key to managing asynchronous objects is to control their visibility, i.e., the way they are visible to the users and applications. Object visibility has many aspects such as object form (regular file, directory and symbolic link) and object accessibility. The IOT-Venus dynamically adjusts different aspects of object visibility of asynchronous objects to serve different needs under different circumstances. The dangling symbolic link representation for inconsistent objects is just one form of visibility control where the accessibility of an inconsistent object is revoked and the form of the object is dynamically transformed to make a visual difference.

5.2.3.2 State-Based Visibility Maintenance

The difficulty of maintaining asynchronous cached objects is that their visibility needs to be dynamically adjusted in response to different kinds of system activities. Events such as a new transaction starting execution, a pending transaction being committed, an invalidated transaction being successfully resolved, and the server replica of an asynchronous object being updated, require the visibility of the relevant objects to be dynamically changed. Because live transactions may create complicated inter-dependencies among themselves, questions such as when an inconsistent object can become a normal object again become very difficult to answer. Our strategy is to use a state-based approach to maintain visibility for cached objects. The key idea is to classify all the cached objects into a small number of states such that any system activity only causes the relevant objects to transit from one state into another. By assigning a specific visibility control policy to each state, visibility maintenance becomes the disciplined action of following state transitions and adjusting visibility accordingly.

Basic States of Cached Objects Any asynchronous cached object obj must have been accessed by at least one live transaction. Each such transaction is called a guardian ofobj. We classify all cached objects into the following four basic states.

Consistent State

An object obj is in the consistent state if it does not have any guardian, i.e., it has not been accessed by any live transaction. The visibility control policy for consistent objects uses the regular callback cache coherence protocol to keep their cache copies

fully synchronized with the corresponding server replicas. In other words, consistent objects are synchronous objects.

Clean-Local State

An objectobjis in the clean-local state if it has at least one guardian and its local version is identical to its current server version, i.e., lv(obj)=gv(obj). This means that

obj is accessed by some live transactions but has not been mutated either locally on the client or globally on the server. It is clean because it has not been updated and it is

local because it must remain in the client cache until all its guardians are committed or

resolved. The visibility control policy for clean-local objects exposes their local state in their original form but pins them inside the client cache so that their server state will not be visible.

Dirty-Local State

An object obj is in the dirty-local state if it has been updated by at least one of its guardians and none of the guardians that mutated obj are invalidated. obj is local because it needs to stay in the client cache until all its guardians are committed or resolved. It is dirty because it has been updated on the client (and by definition not updated on the server). The visibility control policy for dirty-local objects is the same as clean-local objects. Their local state is accessible in their original form but their global state remains invisible.

Inconsistent Object

As previously defined, an objectobjis in the inconsistent state if it has been accessed by at least one invalidated guardianTsuch that it has either been mutated byTor it has been updated on the server. Because accessing inconsistent objects will lead to cascading inconsistencies, the visibility control policy for inconsistent objects prohibits their local or global state from being visible and their form is changed into a dangling symbolic link to visually notify the users about the conflicts.

Under normal circumstances, most of the cached objects are in the consistent state and fully synchronized with their server replicas. A small portion of them remain asynchronous because they are accessed by live transactions. Some of them display their local state in order to represent the tentative computation results of live transactions. Some of them are temporarily inaccessible due to invalidated transactions. Figure 5.2 depicts a visibility distribution among all the cached objects in a client cache.

Object State Transitions The four basic states characterize all the possible situations of any cached object. All the legal transitions among them are shown in Figure 5.3 and explained as follows.

clean-local objects dirty-local objects inconsistent objects consistent objects synchronous asynchronous global state accessible local state accessible inaccessible

Figure 5.2: Visibility of Cached Objects

Consistent Object

A consistent object can become a clean-local or a dirty-local object when it is first read or written by an ongoing transaction respectively. It cannot directly become an inconsistent object because it has to be accessed by a running transaction first in order to be inconsistent.

Clean-Local Object

A clean-local object can go back to be a consistent object when its last guardian is committed or resolved. It can become a dirty-local object when it is updated by an ongoing transaction. In the worst case, it will degenerate into an inconsistent object when its server replica is updated.

Dirty-Local Object

A dirty-local object can similarly go back to be a consistent object when its last guardian is committed. It can become a clean-local object when its last update-guardian is committed while still having other read-guardians. It will fall into the inconsistent state when one of the following two things happens: its server replica is updated or one of its update- guardians is invalidated.

Inconsistent Object

When the last guardian of an inconsistent object obj(it has to be an invalidated trans- action by definition) is resolved, the object is reborn as a fully synchronized consistent

object. The resolution or commitment ofobj’s read-guardians does not change its state. However, ifobjstill has other guardians when an update-guardianTis resolved, it could remain inconsistent if it has other invalidated guardian(s) that have accessed a local version ofobjdifferent from the current global version. Otherwise, objwill become either a clean-local or a dirty-local object depending on whether it has been mutated by the remaining guardians or not.

consistent inconsistent

clean-local dirty-local

Figure 5.3: Cached Object States and Their Transitions

5.3

Conflict Representation in Resolution Mode

The resolution mode is tied to the resolution of one and only one invalidated transaction. The main responsibility of the IOT conflict representation mechanism is to provide the resolver with convenient access to the local and global states of all inconsistent objects accessed by the transaction. For all other objects, only their global state should be visible to the resolver to guarantee that the resolution outcome does not depend on the result of any other live transactions.

Despite its importance in conflict resolution, the issue of how to best represent conflict information to the resolvers has not been adequately addressed in previous research. Our design principle here is to expose conflict information to the resolvers in as simple and concise a form as possible to reduce the burden of programming application-specific resolvers and make the process of manual resolution easier. This section not only presents our novel conflict representation scheme but also studies key alternatives to justify our design decisions.