1. Transactional Information Systems:
Theory, Algorithms, and the Practice of
Concurrency Control and Recovery
Gerhard Weikum and Gottfried Vossen
© 2002 Morgan Kaufmann
ISBN
“Teamwork is essential. It allows you to blame someone else.”(Anonymous)
4/4/2019
Transactional Information Systems

2. Part I: Background and Motivation
1 What Is It All About?
2 Computational Models
4/4/2019
Transactional Information Systems

3. Transactional Information Systems
Transaction Concept
Originally developed in the context of database management systems as a paradigm
for dealing with concurrent accesses to a shared database, and
For handling failures.
We start by describing typical application scenarios for database and other information systems in which transactions make sense.
The application area of the transaction concept includes modern business sectors such as electronic commerce and the management of workflows (which are also known as business processes).
4/4/2019
Transactional Information Systems

4. Transactions – An Abstraction Concept
The key problem that the transaction concept solves in a very elegant way is to cope with the subtle and often difficult issues of keeping data consistent even in the presence of highly concurrent data accesses and despite all sorts of failures.
An additional key property is that this is achieved in a generic way that is essentially invisible to the application logic (and to the application development), so that application developers are completely freed from the burdens of dealing with such system issues.
4/4/2019
Transactional Information Systems

5. Chapter 1: What Is It All About?
1.2 Application Examples
1.3 System Paradigms
1.4 Virtues of Transactions
1.5 Architecture of Database Servers
1.6 Lessons Learned
“If I had had more time, I could written you a shorter letter”
(Blaise Pascal)
4/4/2019
Transactional Information Systems

6. Transactional Information Systems
Application Examples
OLTP, e.g., funds transfer
E-commerce, e.g., Internet book store
Workflow, e.g., travel planning & booking
4/4/2019
Transactional Information Systems

7. OLTP Example: Debit/Credit
void main ( ) {
EXEC SQL BEGIN DECLARE SECTION
int b /*balance*/, a /*accountid*/, amount;
EXEC SQL END DECLARE SECTION;
/* read user input */
scanf (“%d %d”, &a, &amount);
/* read account balance */
EXEC SQL Select Balance into :b From Account
Where Account_Id = :a;
/* add amount (positive for debit, negative for credit) */
b = b + amount;
/* write account balance back into database */
EXEC SQL Update Account
Set Balance = :b Where Account_Id = :a;
EXEC SQL Commit Work; }
Bank operation: traditional teller or home PC with Internet access or credit card reader at a merchant or a cyber cash carrier
4/4/2019
Transactional Information Systems

8. Concurrency and Parallelism
With a huge number of clients potentially issuing simultaneous requests to the bank’s database server, concurrent (i.e. overlapping in time) or even parallel (i.e., on multiple processors) execution of multiple debit/credit transactions in mandatory in order to exploit the server’s hardware resources.
For example, while the server is waiting for the completion of a disk I/O on behalf of one transaction, the CPU should be utilized to process another transaction; similarly, multiple transactions should be processed in parallel on a multiprocessor machine.
4/4/2019
Transactional Information Systems

9. Transactional Information Systems
Isolation
In order to be able to ignore the potential fallacies of the concurrency, it is desirable that each transaction is executed in an isolated manner, that is, as if there were no other transactions and hence no concurrency.
This tension between concurrency for the sake of performance and potential sequential execution for the sake of simplicity and correctness is reconciled by the concurrency control techniques of a transactional server.
4/4/2019
Transactional Information Systems

10. OLTP Example 1.1: Concurrent Executions
P1 Time P2
Select Balance Into :b1
From Account
Where Account_Id = :a
/* b1=0, a.Balance=100, b2=0 */
Select Balance Into :b2
2 From Account
/* b1=100, a.Balance=100, b2=100 */
b1 = b
/* b1=50, a.Balance=100, b2=100 */
4 b2 = b2 +100
/* b1=50, a.Balance=100, b2=200 */
Update Account
Set Balance = :b
/* b1=50, a.Balance=50, b2=200 */
6 Set Balance = :b2
/* b1=50, a.Balance=200, b2=200 */
Observation: concurrency or parallelism may cause inconsistencies,
requires concurrency control for “isolation”
4/4/2019
Transactional Information Systems

11. OLTP Example 1.2: Funds Transfer
void main ( ) {
/* read user input */
scanf (“%d %d %d”, &sourceid, &targetid, &amount);
/* subtract amount from source account */
EXEC SQL Update Account
Set Balance = Balance - :amount Where Account_Id = :sourceid;
/* add amount to target account */
Set Balance = Balance + :amount Where Account_Id = :targetid;
EXEC SQL Commit Work; }
Observation: failures may cause inconsistencies,
require recovery for “atomicity” and “durability”
4/4/2019
Transactional Information Systems

12. Atomicity and Durability
The various accesses a transaction has to perform need to occur in conjunction: once a transaction has started, the data accesses should look to the outside world as an atomic operation that is either executed completely or not at all.
This atomicity property should be guaranteed to hold even in a failure-prone environment where the individual processes or the entire database server may fail in an arbitrarily inconvenient point in time. To this end, a transactional server provides recovery techniques to cope with failures: to ensure durability of a transaction’s effects once the transaction is completed.
4/4/2019
Transactional Information Systems

13. Transactional Information Systems
E-Commerce Example
Shopping at Internet book store:
client connects to the book store's server and
starts browsing and querying the store's catalog
client fills electronic shopping cart
upon check-out client makes decision on items to purchase
client provides information for definitive order
(including credit card or cyber cash info)
merchant's server forwards payment info to customer's bank
credit or card company or cyber cash clearinghouse
when payment is accepted,
shipping of ordered items is initiated by the merchant's server
and client is notified
Observations: distributed, heterogeneous system
with general information/document/mail servers
and transactional effects on persistent data and messages
4/4/2019
Transactional Information Systems

14. Transactional Information Systems
Workflows
A workflow is a set of activities that belong together in order to achieve a certain business goal. Examples are:
Processing an insurance claim in an insurance company;
Work of a program committee for a scientific conference
Submissions, reviews, notifications, etc.;
The administrative procedures for real estate purchase; and
“routing” of a patient in a hospital.
To orchestrate such processes, it is crucial to specify (at least a template for) the control flow and the data flow between activities, although it may still be necessary to improvise at run time (e.g., in medical applications).
4/4/2019
Transactional Information Systems

15. Transactional Information Systems
Workflow Management
Activities may be completely automated or based on interaction with a human user and intelligent decision making. They are typically distributed across different reasonable persons and different independent information systems, possibly across different enterprises.
A workflow management system provides a specification environment for registering activities and for specifying, in a high-level declarative way, not only the control and data flow within a process, but also a run-time environment that automatically triggers activities according to the specified flow.
4/4/2019
Transactional Information Systems

16. Transactional Information Systems
Workflow Example
Workflows are (the computerized part of) business processes,
consisting of a set of (automated or intellectual) activities
with specified control and data flow between them
(e.g., specified as a state chart or Petri net)
Conference travel planning:
Select a conference, based on subject, program, time, and place.
If no suitable conference is found, then the process is terminated.
Check out the cost of the trip to this conference.
Check out the registration fee for the conference.
Compare total cost of attending the conference to allowed budget,
and decide to attend only if the cost is within the budget.
Observations: activities spawn transactions on information servers,
workflow state must be failure-resilient,
long-lived workflows are not isolated
4/4/2019
Transactional Information Systems

17. Example: Travel Planning Workflow
CheckConfFee
/ Budget:=1000;
Trials:=1; Go
Select
Conference
Select
Tutorials
Compute
Fee
[Cost  Budget]
/ Cost =
ConfFee +
TravelCost
Check
Cost
[ConfFound]
/ Cost:=0
Check
Áirfare
[Cost > Budget
& Trials  3]
[!ConfFound]
Check
Hotel No
CheckTravelCost
[Cost > Budget & Trials < 3] / Trials++
4/4/2019
Transactional Information Systems

18. Chapter 1: What Is It All About?
1.2 Application Examples
1.3 System Paradigms
1.4 Virtues of Transactions
1.5 Architecture of Database Servers
1.6 Lessons Learned
4/4/2019
Transactional Information Systems

19. 3-Tier System Architectures
Clients:
presentation (GUI, Internet browser)
Application server:
application programs (business objects, servlets)
request brokering (TP monitor, ORB, Web server)
based on middleware (CORBA, DCOM, EJB, SOAP, etc.)
Data server:
database / (ADT) object / document / mail / etc. servers
Specialization to 2-Tier Client-Server Architecture:
Client-server with “fat” clients (app on client + ODBC)
Client-server with “thin” clients (app on server, e.g., stored proc)
4/4/2019
Transactional Information Systems

20. 3-Tier Reference Architecture
Stored
Data
(Pages)
Server
Application
Clients
Users
. . .
Program 1
Program 2
...
Objects
encapsulated
data
exposed
Request
Reply
4/4/2019
Transactional Information Systems

21. Transactional Information Systems
System Federations
Data
Servers
Application
Clients
Users
. . .
...
4/4/2019
Transactional Information Systems

22. Chapter 1: What Is It All About?
1.2 Application Examples
1.3 System Paradigms
1.4 Virtues of Transactions
1.5 Architecture of Database Servers
1.6 Lessons Learned
4/4/2019
Transactional Information Systems

23. ACID Properties of Transactions
Atomicity:
all-or-nothing effect,
simple (but not completely transparent) failure handling
Consistency-preservation:
transaction abort upon consistency violation
Isolation:
only consistent data visible as if single-user mode,
concurrency is masked to app developers
Durability (persistence):
committed effects are failure-resilient
Transaction programming interface (“ACID contract”)
begin transaction
commit transaction (“commit work” in SQL)
rollback transaction (“rollback work” in SQL)
4/4/2019
Transactional Information Systems

24. Requirements on Transactional Servers
Server components:
Concurrency Control
guarantees isolation
Recovery:
guarantees atomicity and durability
Performance:
high throughput (committed transactions per second)
short response time
Reliability:
(almost) never lose data despite failures
Availability:
very short downtime
almost continuous, 24x7, service
4/4/2019
Transactional Information Systems

25. Chapter 1: What Is It All About?
1.2 Application Examples
1.3 System Paradigms
1.4 Virtues of Transactions
1.5 Architecture of Database Servers
1.6 Lessons Learned
4/4/2019
Transactional Information Systems

26. Database System Layers
Server
Clients
. . .
Requests
Language & Interface Layer
Query Decomposition &
Optimization Layer
Query Execution Layer
Access Layer
Storage Layer
Data
Accesses
Request
Execution
Threads
4/4/2019
Transactional Information Systems

27. Transactional Information Systems
Storage Structures
Database
Extent
Table
Page
Page Header
Slot Array
Ben 55
Las Vegas
...
Sue 23
Seattle
Joe 29
San Antonio
free space
forwarding
RID
---
Extents
4/4/2019
Transactional Information Systems

28. Transactional Information Systems
Access Structures
Adam
Bill
Dick
Eve
Hank
Jane
Bob
Jill
Tom
Root Node
Leaf Nodes
RIDs
B+-tree
Search tree interface:
lookup <index> where <indexed field> = <search key>
lookup <index> where <indexed field>
between <lower bound> and <higher bound>
4/4/2019
Transactional Information Systems

29. Transactional Information Systems
Query Execution Plans
Select Name, City, Zipcode, Street
From Person
Where Age < 30
And City = "Austin"
Index Scan
on CityIndex
RID Access
Fetch Person
Record
Filtering
Projection
Index Scan
on AgeIndex
on CityIndex
RID List
Intersection
RID Access
Fetch Person
Record
Projection
4/4/2019
Transactional Information Systems

30. Chapter 1: What Is It All About?
1.2 Application Examples
1.3 System Paradigms
1.4 Virtues of Transactions
1.5 Architecture of Database Servers
1.6 Lessons Learned
4/4/2019
Transactional Information Systems

31. Transactional Information Systems
Lessons Learned
Benefits of ACID contract:
For users: federation-wide data consistency
For application developers: ease of programming
Server obligations:
Concurrency control
Recovery
4/4/2019
Transactional Information Systems