The Transaction Concept: Virtues and Limitations

1
The Transaction Concept Virtues and Limitations

• Jim Gray
• Presented by Thu D. Nguyen

2
Oldy but Goody

• This is one of the clearest explanation of the
  transaction concept I have ever seen
• What is a transaction?
• Its a contract between two or more parties
• that is agreed to by all parties
• and is binding on all parties

3
Transaction

• What does it mean in computer systems?
• View system state as comprised of records and
  devices with changeable values
• The system contains assertions about the possible
  values and allowed transformations
• Think of this as really the set of laws that we
  obey when negotiating a contract
• We say that the system is in a consistent state
  if all assertions are true
• and a set of operations to read and/or transform
  the state
• An action seems to be either equivalent to an
  operation or a set of operations

4
Transaction (contd)

• A transaction is then any set of operations that
  leads from one consistent state to another
• A transaction is said to have four properties
• A atomicity
• C Consistence
• I Isolation
• D Durable
• Gray does not mention I explicitly but does
  discuss it when he talks about commit and abort
  and locking
• Anything wrong with this model?

5
Clarifying Actions

• Unprotected
• Action does not need to be undone if transaction
  aborts
• Action does not need to be redone if values of
  affected entities (records or device) need to be
  reconstructed
• Protected
• Action needs to be undone if transaction aborts
• Action needs to be redone if values of affected
  entities need to be reconstructed
• Real
• Once done, the action cannot be undone

6
Transaction Outcomes

• Committed
• The accumulated effects of all protected and real
  actions performed as part of the transaction must
  persist, even in the presence of failures
• Aborted
• The effects of protected and real actions
  performed as part of the transaction must never
  be seen by another transaction (that eventually
  commits)
• Real actions
• If you want real actions inside a transaction to
  be unseen when that transaction aborts, you
  cannot perform that action until you know that
  the transaction is going to commit
• What if in the middle of doing a sequence of real
  actions and one of them fail?

7
Nested Transactions

• If there are lots of actions inside a single
  transaction, the transaction might take too long
  or the probability of conflict with another
  transaction might become too high
• A transaction might be thought of as comprised of
  a set of nested transactions
• Some nested transactions might run in parallel
• The parent transaction can commit or abort
  regardless of commit or aborts of nested
  transactions
• Commit means that all actions of nested
  transactions that committed and any of the
  transaction itself will persist
• If the parent aborts, all nested transactions
  must abort
• Results of nested transactions are not visible
  outside of the parent transaction until commit of
  the parent transaction

8
Hardware and Software Reliability

• Gray argues that
• People know how to build reliable hardware by
  making use of redundancy
• Hardware components have self-checking tests to
  assure a fail-fast model
• Hardware components can be duplicated to tolerate
  faults
• However, building fault-tolerance software on top
  of this reliable hardware is HARD!
• Transaction makes building fault-tolerant
  software easier because it provides a clean model
  to deal with failures

9
Implementation Details

• Time-domain addressing
• Basic idea keep all versions of records (and
  devices) and address by name and version (logical
  time)
• Have system of updating time of records when read
  or modified so that can know to abort or commit
  transactions
• Im not sure but I dont think this method is
  used much anymore

10
Implementation Details

• Lock, logging, and 2-phase commit
• Logs allow undo and redo
• Locking support isolation (or serialization)
• Strict 2-phase locking prevents cascaded abort
• 2-phase commit allows all parties that
  participated in a transaction to agree or
  disagree at commit time

11
Limitations

• Long-lived transactions
• Deadlocks
• Block other transactions for too long
• Nested transactions
• If we allow results of committed sub-transactions
  to be seen by other transactions, then atomicity
  and serializability are both broken
• If we dont, then we have problem with long-lived
  transactions
• Integration into language
• Done with various systems Argus from MIT (1985)
  is one example
• Java anyone?