Subject: System

Keywords: ::implementation
          ::algorithm

Title: Sequentializing Concurrent Transactions

--------------------------------------------------

See transaction 


Problem :
 Need committed updates to be in effect prior to any access by a transaction 
 that begins after the completion of any earlier write transaction.

  check on end-hook transactions, looks like multiple happen simulaneously when should
  be sequential

Note this is not about detecting or handling clashes but about being certain
that non clashing updates of prior transactions are visible at start of transaction. 

Two cases:
  - replicated library 
      * broadcast from tx to as single message.
  - simultaneous in same library
      * initiated in library,
      * initiated by client
          ! possible does reads before lib receives begin from tx 
      * uprgrade by client (editor only)
  

Transaction Manager : 
  - sequentializes time stamps for all relevant transaction events.
      * such sequentialized stamps can be trivially ordered
  - committed updates whose stamps come before the begin stamp of a transaction
    must be broadcast and applied to client trans-tables prior to reads
    of trans table by newer transaction.
  - broadcasts updates and begins to libraries in sequential order  

Library :
  Must prevent new transaction from evaluating prior to finishing completions
  of earlier transactions.
  - lib requests completion at completion start, tx will sequentialize with replicated.
  - dispatcher receives tx broadcasts in fifo order.
  - sequentializer - sequentializes updates from replicated libs and local commits.
      * do-completions : enqueues do-commits to squentializer
        holds completion-lock during : 
          - calls tx with updates
          - sequentialize do-commits
          - rsp to tx call will bed enqueued to eval-thread by dispatcher?
      * transaction-server-broadcasts
          - runs in dispatcher thread
          - transaction server broadcast enqueues to sequentializer 
      ! thus a later replicated broadcast could get ahead of local commit.
        do-completions calls tx holding completion-lock and evaluation-lock
        (shouldn't rely on evaluation-lock to sequentialize this, not that it is?)
        if eval-thread pauses between tx-call and do-commits
    !!! don't see it sequentializing updates with begins !!!
lib receives transaction-stamp term as rsp to transaction_update req

Clients:
  Must process update broadcasts prior to evaluating newer transactions.
  - broadcast sequentializer    
  ⋅
--------------------------------------------------

Authors: NUPRL:t

⋅

Home