Transaction Primitives

transaction_id *begin_transaction(int ctb,int mtb,int etb)

FILE *t_open(transaction_id tid,char *pathname,char *mode)

int t_close(transaction_id tid,FILE *fp)

void abort_transaction(transaction_id tid)

transaction_status end_transaction(transaction_id tid)

transaction_status status_transaction(transaction_id tid)

Since these have not been implemented I will not use a lot of space on discussing their use. Instead I will give a few notes and give an example of how I imagine them used:

All reads and writes using the file pointer returned by a transactional open, t_open(*tid,...), are considered part of the transaction identified by tid.

Before an abort_transaction all open files that are part of the transaction (i.e., opened using t_open) must be closed explicitly.

The application can test (using status_transaction) for the status of a transaction, and re-execution of the transaction is the responsibility of the application--the system does not provide any functionality of such sort. The possible statuses of a transaction is given in Table 5.8.

Example use of transactions are given in Figures 5.9 and 5.10 pp.

. Please note that these are examples of how I think it could be done--it has not been implemented!

The optimism, strictness, or pessimism of the transaction is tied to the distributed file service using the same (notions of) consistency, modification, and expiration time bounds.

E.g., if the transaction is a pessimistic one (and communication is good enough to get the changes to the server "in time") then COMMITED_ON_CLIENT is sufficient; the updates are guaranteed to reach the server due to the obtained write-locks, and the reads are guaranteed to be consistent due to the obtained read-locks. If the locks were not obtained, the transaction would have failed.

On the server a transaction could be uniquely identified by the transaction id (from the client) and a machine (the client's) id (i.e., IP-number).

**Table 5.8:** Transaction status values
Status	Meaning
`NOTBEGUN`	Unable to start; `begin_transaction` failed?
`RUNNING_ON_CLIENT`	Transaction is executing on the client
`ABORTED`	Explicitly aborted using `abort_transaction`
`ABORTED_ON_CLIENT`	Attempt to commit on client side failed
`COMMITED_ON_CLIENT`	All transactional statements succeeded on client
`RUNNING_ON_SERVER`	Transaction is attempting commit on the server
`ABORTED_ON_SERVER`	Attempt to commit on server failed
`COMMITED_ON_SERVER`	All transactional statements succeeded

Whether a successful implementation based on these ideas is possible or not, only the future can tell. I rest my case.