Contents   Index

Conflicts

Since optimistic write operations are allowed, conflict situations are unavoidable. Since I chose session semantics for file operations then conflicts for a given file can only be detected after that file has been closed.

If it takes some amount of time before the updates are propagated to the server, then it is impossible to report failure or success immediately, that is, whether there is a conflict or not. We could let the close operation block until "the matter has been sorted out", but not all applications are geared to do so--they probably expect the close to return immediately. How long an application can wait is specific to that application, so a way of letting the application tell the system, how long it is prepared to wait, is needed. I chose to associate yet another time bound with the close operation (well along the line of the other operations)--the Expiration Time Bound ($ET \! B$).

Imagine a client closing a file, f, by issuing a command similar to:

close(f,$ET \! B$)

A close command, like the one above, will not return until either all updates have been propagated successfully back to the server, or a conflict has been detected, or it times out (expires) according to the specified time bound (see Figure 5.3). The command can return SUCCESS, FAILURE, or TIMEOUT.

Figure 5.3: Expiration Time Bound (ETB)

If the close times out then the application can take appropriate actions, e.g., inform the users that they must check f later (themselves) because it cannot say whether the close eventually succeeds or not!^5.4

If the close results in failure and the file was opened for writing, then the application can inform the user that his or her updates failed, and copy the contents of the cached file to another (new) file (or do whatever actions it deems necessary). If the file was opened for reading and the close fails then it means that the user have been reading stale data (i.e., from a file that has been updated on the server in the meantime); the application can ignore this or, if it is "polite", inform the user.

The primitive for closing a file is the ANSI-C [21] fclose with an added parameter for specifying the expiration time bound:

• ANSI-C: int fclose(FILE *fp);
• $\mathcal{P}$$e$$\mathcal{S}$$t$$\mathcal{O}$: int p_close(FILE *fp,int etb);

The two following subsections are dedicated to the matters of how conflicts are best avoided, when they are detected, and how they can be resolved! First subsection is about read/write conflicts and the other about write/write conflicts.

Footnotes

... not!^5.4

It may be a good idea to provide some way for the application to check at a later stage, but the current implementation does not.

  Contents   Index