Shared Flashcard Set


COMP3017 - Lecture 6 (A) - Transactional Models
COMP3017 - Lecture 6 (A) - Transactional Models
Computer Science
Undergraduate 2

Additional Computer Science Flashcards




What are some procesing styles and state their characteristics?
What are some characteristics of tansactional oriented processing?
  • Sharing access to data
  • Variable requests
  • Repetitive workload
  • Mostly simple functions
  • Some batch transactions
  • Many terminals
  • High availability
  • System takes care of recovery
  • Automatic load balancing
What are some characteristics of Flat transactions?
  • The simplest type of transaction
  • Basic building block for other models
  • Only one layer of control by the application - hence "flat"
    • Begin work
    • Commit work or abort work
  • All or nothing processing


What are some limitations of flat transactions?
  • Long lived transactions present particular challenges:
    • More likely to be interrupted (rollback not acceptable)
    • May access many data items
      • Cannot hold locks indefinitely - will lead to deadlocks
  • Simple control structure cannot model more complex applications
    • Trip planning
    • Bulk updates
  • Does not allow much co-operation
  • May be too strict
  • Databases used in advanced applications
    • CAD/CAM
    • Office automation
    • Software development
What are some requirements for transactions?

Controlling computations in a distributed multi-user environment primarily means:

  • Containing the effects of arbitrary operations as long as there might be a necessity to revoke them
  • Monitoring the dependencies of operations on each other in order to be able to trace the execution history in case faultry data are found at some point
What are some characteristics of transaction processing context?
  • Example: Counters, user-related data, information about durable storage, etc
  • Needed for long lived transactions
  • One way is for the application to maintain a context as a database record
  • For a simple program
    • output_message = f {input_message}
  • More typically, however,
    • f{input_message,context} -> {output_message, contect}
    • where context might be a cursor position
What are some characteristics of persistent savepoints?
  • Following a system crash, restart in-flight transactions from their most recent savepoints
  • Needs whole context preserved (only system variables, no need for program variables)
  • Programming languages have limitations (persistent programming language needed)


Give an example of a chained transaction.
  1. Begin work
  2. Chain transaction
    1. Commit results 
    2. Keep [some] locks
    3. Keep cursors
    4. Continue processing
  3. Noone else can access kept objects
  4. Application cannot rollback to before 'Chain Transaction'
Give some comparison between Savepoints vs. Chained Transactions
  • Both allows substructure to be imposed on a long-running application program
    • Database context is preserved
    • Cursors are kept
  • Commit vs Savepoint
    • Chained - rollback only to previous 'savepoint'
    • Savepoints - can rollback to arbitrary savepoint
  • Locks
    • Chained frees unwanted locks
  • Work lost
    • Savepoints are more flexible than flat transactions as long as the system does not crash
  • Restart
    • Chained can restart from most recent commit as long as no processing context hidden in local programming variables
  • Both organize work into a sequence of actions


What are the tree main rules for nested transactions?
  • Commit Rule
    • The commit of a subtransaction makes the results accessible only to the parent
    • The final commit happens only when all ancestors finally commit
  • Rollback Rule
    • If any [sub]transaction rolls back, all of its subtrasactions roll back
  • Visibility Rule
    • Changes made by a subtransaction are visible to its parent
    • Objects held by a parent can be made accessible to subtransactions
    • Changes made by subtrasnactions are not visible to silbings
What are some characteristics of subtransactions?
  • Subtransactions are:
    • Atomic
    • Consistency preserving
    • Isolated
    • Not durable, because of commit rule
  • Nesting and program modularization complement each other
    • Well designed module has a clean interface, and no global variables
    • If it touches the database, the database is a large global variable
    • If the module is protected as a subtransaction then database changes are kept clean too
  • Nested transactions permit intra-transaction parallelism
What are some characteristics of emulating nesting with savepoints?
  • Using savepoints is more flexible than nested for internal recovery
    • Can roll back further
  • True nested is needed in order to run subtransactions in parallel (Intra-transaction parallelism)
    • Emulating with savepoints needs subtransactions to be run in strict sequence
  • True nested can pass locks selectively
    • More flexible than savepoints
    • Similar but different
What are some characteristics of distributed transactions?
  • A flat transaction has to visit several nodes to collect data
    • Differs from nested; only one level
    • If a subtransaction, which is just a slice of the main transaction, commits or rolls back, the whole transaction does the same
What are some characteristics of multi-level transactions?
  • A generalized, and more liberal version of nested transactions
  • Multi-level transactions have the ability to pre-commit the results of a subtransaction
    • Therefore cannot do unilateral backout of updates
  • A 'Compensating Transaction is needed to reverse effects, if necessary
  • Scheme of layering object implementation ensures ACIDity at the root level
What are characteristics of compesating transactions?
  • The compensating transaction needs careful thought
  • It mus tbe available form the point of subtransaction commit
  • It must not abort
    • Needs provision to survive system failure
    • Needs provision to survive internal error (SQL call fails)
  • If it is not needed, the compensating transaction must be disposed of when the application finally completes
What are some characteristics of layering?
  • Abstraction hierarchy
    • The entire system consists of a strict hierarchy of objects with their associated operations
  • Layered abstraction
    • The objects of layer 'n' are completely implemented by using operations of layer 'n-1'
  • Discipline
    • There are no shortcuts that allow layer 'n' to access objects on a layer other than 'n-1'
  • Other models use early commit
    • Open Nested, Sagas, Engineering transactions...
  • Only multi-level transactions have all ACID properties
What are the requirements of the long lived transactions?
  • Minimize work lost
    • Split up to control the amount of work lost
  • Recoverable computation
    • There must be ways to temporarily stop the computation without having to commit the results and without causing rollback because of shutdown
  • Explicit control flow
    • Systems must be able to control the sequence
    • Possible to proceed along prespecified path, or to remove the effects of what has happened so far
Supporting users have an ad free experience!