![]() ![]() ![]() ![]() ![]() Next: Boundaries of Transactions Up: Concurrency Control Previous: Concurrency Control   Contents   Index |
begin <For each file read or written, or until ROLLBACK, do the following: 1. has the file been changed (on the server) so that it is inconsistent with the version the transaction operated on, then ROLLBACK 2. has the file been locked (explicit by pessimistic read or write operations, or implicit by another transaction), then ROLLBACK 3. if neither 1. nor 2. is the case, then put a lock on the file > <If all files operated on have been successfully locked then: - make a copy of all the files (in case something goes wrong) - alter all the updated files - see to that all changes are written to stable storage - release all the locks, thereby completing the COMMIT > end |
The algorithm does not serialize the transactions on the server, i.e.,
at , but since I have decided not to provide isolation that is not a
problem. Neither step 1 nor step 2 in the algorithm could lead to ROLLBACK,
if the transaction was pessimistic--the files would have been locked by that
transaction, and thus could not have been changed not locked by other operations
or transactions!