next up previous contents index
Next: Boundaries of Transactions Up: Concurrency Control Previous: Concurrency Control   Contents   Index


Optimistic Concurrency Control

I suggest a new optimistic concurrency control mechanism based on private workspace and modification times, i.e., instead of checking what the other transactions are doing at commit-time (as in Kung and Robinson's Optimistic Concurrency Control algorithm [29]). I wish to check only the state of the files, see Figure 4.2 (p. [*]).

Figure 4.2: A new algorithm for optimistic concurrency control
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 $SCT$, 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!



michael@garfield.dk
2000-10-13