Formal models of concurrency

and communication
based on the slides of Gottfried Vossen,
Univ. of Münster, Germany
 Formal models of concurrency and
communication
• Introduction. Concurrent Models
• Concurrency control: serialization, complexity, control,
conflicts, algorithms
• Concurrency control for the object model
• Concurrency control in relational databases
• Failure & Recovery modeling: recovery in page, object and
multimedia model
• Distributed concurrency control
• CCS (Calculus of Communication Systems) models for
concurrent processes
• Pi-Calculus models for concurrent processes
Part I: Introduction. Concurrent Models

• 1 What Is It All About?

• 2 Computational Models
 1. What Is It All About?

• 1.1 Application Examples

• 1.2 System Paradigms
• 1.3 Virtues of Transactions
• 1.4 Architecture of Database Servers
• 1.5 Lessons Learned
 Serial vs. Concurrent vs. Parallel
computation
Sequential processes Concurrent processes Parallel processes

time
shared data

low clarity & correctness, relatively

high performance

very good clarity, correctness, low good clarity & correctness, high
performance performance
 Producer-consumer scenario
Producer Consumer
Read(x);
Read(x); x--;
x++; Write(x);
Write(x); …
…. Read(x);
Read(x); x--;
x++; Write(x);
Write(x); …
…

=> Atomicity is enough

 Application Examples

• OLTP, e.g., funds transfer

• E-commerce, e.g., Internet book store
• Workflow, e.g., travel planning & booking
 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;
}
 OLTP Example 1.1: Concurrent Executions
P1 Time P2
Select Balance Into :b1
From Account 1
Where Account_Id = :a
/* b1=0, a.Balance=100, b2=0 */
Select Balance Into :b2
2 From Account
Where Account_Id = :a
/* b1=100, a.Balance=100, b2=100 */
b1 = b1-50 3
/* b1=50, a.Balance=100, b2=100 */
4 b2 = b2 +100
/* b1=50, a.Balance=100, b2=200 */
Update Account
Set Balance = :b1 5
Where Account_Id = :a
/* b1=50, a.Balance=50, b2=200 */
Update Account
6 Set Balance = :b2
Where Account_Id = :a
/* b1=50, a.Balance=200, b2=200 */

Observation: concurrency or parallelism may cause inconsistencies,

requires concurrency control for “isolation”
 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 */
EXEC SQL Update Account
Set Balance = Balance + :amount Where Account_Id = :targetid;
EXEC SQL Commit Work; }

Observation: failures may cause inconsistencies,

require recovery for “atomicity” and “durability”
 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
 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
Example: Travel Planning Workflow
 Introduction

• 1.1 Application Examples

• 1.2 System Paradigms
• 1.3 Virtues of Transactions
• 1.4 Architecture of Database Servers
• 1.5 Lessons Learned
 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)
 3-Tier Reference Architecture
Users
Clients ...
Request Reply
Application Application Application
Server Program 1 Program 2 ...
Request Reply
encapsulated exposed
data data
Data Objects
Server ...

Stored
Data
(Pages)
 System Federations
Users
Clients ...
Application
Servers
...

Data
Servers
...
 Introduction

• 1.1 Application Examples

• 1.2 System Paradigms
• 1.3 Virtues of Transactions
• 1.4 Architecture of Database Servers
• 1.5 Lessons Learned
 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)
 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
 Introduction

• 1.1 Application Examples

• 1.2 System Paradigms
• 1.3 Virtues of Transactions
• 1.4 Architecture of Database Servers
• 1.5 Lessons Learned
Database System Layers
Storage Structures
 Access Structures

Root Node
Bob Eve Tom

B+-tree

Adam Bill Bob Dick Eve Hank Jane Jill Tom

Leaf Nodes
RIDs

Search tree interface:

• lookup <index> where <indexed field> = <search key>
• lookup <index> where <indexed field>
between <lower bound> and <higher bound>
 Query Execution Plans
Select Name, City, Zipcode, Street
From Person
Where Age < 30
And City = "Austin"

Projection
Projection

Filtering
RID Access

RID List RID Access

Intersection

Index Scan Index Scan Fetch Person Index Scan Fetch Person
on AgeIndex on CityIndex Record on CityIndex Record
 Introduction

• 1.1 Application Examples

• 1.2 System Paradigms
• 1.3 Virtues of Transactions
• 1.4 Architecture of Database Servers
• 1.5 Lessons Learned
 Lessons Learned

• Benefits of ACID contract:

▪ For users: federation-wide data consistency
▪ For application developers: ease of programming

• Server obligations:
▪ Concurrency control
▪ Recovery
 2. Computational Models

• 2.1 Ingredients
• 2.2 Page Model
• 2.3 Object Model
Reminder: Database System Layers
 Ingredients

• Elementary operations
• Transactions (i.e., transaction program executions)
• Histories and schedules
• Characterization of correct schedules
• Protocols (i.e., rules for online algorithms)
 2. Computational Models

• 2.1 Ingredients
• 2.2 Page Model
• 2.3 Object Model
 Math concepts (partial and total order
relations)
Definition (Partial Order): Let A be an arbitrary set. A
relation R  A x A is a partial order on A if the following
conditions hold for all elements a, b, c  A:
1. (a, a)  R
(reflexivity)
2. (a, b)  R and (b, a)  R  a=b (antisymmetry)
3. (a, b)  R and (b, c)  R  (a, b)  R
(transitivity)

A total order relation has the additional requirement that for

any two distinct a, b  A, either (a, b)  R or (b, a)  R.
 Page Model
“Syntax”:
Definition (Page Model Transaction):
A transaction t is a partial order of steps (actions) of the form
r(x) or w(x), where x  D and reads and writes as well as multiple
writes applied to the same object are ordered.
We write t = (op, <)
for transaction t with step set op and partial order <.

Example: r(s) w(s) r(t) w(t)

“Semantics”:
Interpretation of jth step, pj, of t:
If pj=r(x), then interpretation is assignment vj := x to local variable vj
If pj=w(x) then interpretation is assignment x := fj (vj1, ..., vjk).
with unknown function fj and j1, ..., jk denoting t‘s prior read steps.
 2. Computational Models

• 2.2 Ingredients
• 2.3 Page Model
• 2.4 Object Model
 Object Model
Definition (Object Model Transaction):
A transaction t is a (finite) tree of labeled nodes with
• the transaction identifier as the label of the root node,
• the names and parameters of invoked operations as labels of
inner nodes, and
• page-model read/write operations as labels of leaf nodes,
along with a partial order < on the leaf nodes such that
for all leaf-node operations p and q with p of the form w(x)
and q of the form r(x) or w(x) or vice versa, we have p<q  q<p

Special case: layered transactions

(all leaves have same distance from root)
Derived inner-node ordering: a < b if
all leaf-node descendants of a precede all leaf-node descendants of b
 Example: DBS Internal Layers

t1

Search (“Austin”) Fetch(x) Fetch(y) Store(z)

r (r) r (l) r (p) r (q) r (f) r (p) w (p) r (r) r (l) w (l)
 Example: Business Objects
t2

Withdraw (x, 1000) Deposit (y, 1000)

Append (h, ...)

^
Search (...) Fetch (x) ^ Fetch (a) Fetch (d) Store (e) Modify (d) Modify (a) ^
Search (...) Fetch (y) ^
Modify (x) Modify (y)

r (r) r (l) r (p) r (p) w (p) r (s) r (t) r (t) w (t) r (t) w (t) r (s)w (s) r (r) r (l) r (q) r (q) w (q)