• 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

• 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

[image]

• 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

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

• 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

• 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)

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'

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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

• 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