The suggested transaction interface is:
- 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
- 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
- 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
Transaction status values
||Unable to start; begin_transaction failed?
||Transaction is executing on the client
||Explicitly aborted using abort_transaction
||Attempt to commit on client side failed
||All transactional statements succeeded on client
||Transaction is attempting commit on the server
||Attempt to commit on server failed
||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.