Molecular Transactions
G. Ramalingam
Kapil Vaswani
Rigorous Software Engineering, MSRI
Simple banking application
ACID Transaction
Account#
Name
Balance
XXXX0123
ABC
10000
XXXX3452
XYZ
20000
let transfer from to amount =
atomic {
match hasBalance from amount with
| true ->
debit from amount
credit to amount
SUCCESS
| false -> INSUFFICIENT_BALANCE
}
Database
Application
server
Rigorous Software Engineering
Microsoft Research, India
?
Rigorous Software Engineering
Microsoft Research, India
Scalable applications
• Support lots of users
– TBs of data!
– Many concurrent transactions
– Unpredictable workload
• Key requirements
Application
server
Relational
Database
– Available
– Fault tolerant
– Data consistency
• Achieving all at the same time
non-trivial!
Rigorous Software Engineering
Microsoft Research, India
Designing for scale
Rigorous Software Engineering
Microsoft Research, India
Scaling application tier
Application
server
Database
Rigorous Software Engineering
Microsoft Research, India
Replication
Application
server
Replica
Replica
Rigorous Software Engineering
Microsoft Research, India
Replica
Data partitioning
Application
server
Data
partition
Data
partition
Rigorous Software Engineering
Microsoft Research, India
A first-class
citizen in cloud
based storage
systems
Horizontal data partitioning
Branch
XXXX01
Account#
XXXX0123
Name
ABC
Balance
10000
Database
partition
XXXX34
Account#
XXXX3452
Distributed vs. local
transactions
Distributed transactions
do not scale 
Database
partition
Branch
let transfer from to amount =
let status =
atomic {
match hasBalance from amount with
| true ->
debit from amount
DEBIT_COMPLETE
| false -> INSUFFICIENT_BALANCE
}
Name
XYZ
Balance
20000
atomic {
match status with
| DEBIT_COMPLETE ->
credit to amount
SUCESSS
| _ -> INSUFFICIENT_BALANCE
}
Azure tables, BigTable,
Dynamo do not support
distributed transactions!
Rigorous Software Engineering
Microsoft Research, India
Consistency
Account#
XXXX0123
Name
ABC
Balance
5000
Database
partition
Database
partition
Account#
XXXX3452
Name
XYZ
Balance
20000
let transfer from to amount =
let status =
atomic {
match hasBalance from amount with
| true ->
debit from amount
DEBIT_COMPLETE
| false -> INSUFFICIENT_BALANCE
}
atomic {
match status with
| DEBIT_COMPLETE ->
credit to amount
SUCESSS
| _ -> INSUFFICIENT_BALANCE
}
Rigorous Software Engineering
Microsoft Research, India
Rigorous Software Engineering
Microsoft Research, India
Compute failures
Account#
XXXX0123
Name
ABC
Balance
5000
Database
partition
let transfer from to amount =
let status =
atomic {
match hasBalance from amount with
| true ->
debit from amount
DEBIT_COMPLETE
| false -> INSUFFICIENT_BALANCE
}
Server
failures
Database
partition
Account#
XXXX3452
Name
XYZ
Balance
20000
Rigorous Software Engineering
Microsoft Research, India
Handling compute failures
Account#
Name
XXXX0123
ABC
Balance
5000
Database
partition
Checkpoint
storage
Database
partition
Account#
XXXX3452
Name
XYZ
Balance
20000
let transfer from to amount =
let status =
atomic {
match hasBalance from amount with
| true ->
debit from amount
DEBIT_COMPLETE
| false -> INSUFFICIENT_BALANCE
}
atomic {
match status with
| DEBIT_COMPLETE ->
credit to amount
SUCESSS
| _ -> INSUFFICIENT_BALANCE
}
Rigorous Software Engineering
Microsoft Research, India
There’s more…logical failures
Account#
XXXX0123
Name
ABC
Balance
5000
Database
partition
Database
partition
Account#
XXXX3452
Name
XYZ
Balance
let transfer from to amount =
let status =
atomic {
match hasBalance from amount with
| true ->
debit from amount
DEBIT_COMPLETE
| false -> INSUFFICIENT_BALANCE
}
What if credit fails?
e.g. account closed
20000
Rigorous Software Engineering
Microsoft Research, India
Handling logical failures with
compensating actions
let transfer from to amount =
let status =
atomic {
match hasBalance from amount with
| true ->
debit from amount
DEBIT_COMPLETE
| false -> INSUFFICIENT_BALANCE
}
let compensate from amount =
atomic {
credit from amount
}
Credit fails
Rigorous Software Engineering
Microsoft Research, India
Molecular transactions
Fault-tolerant composition of atomic
transactions with compensating actions
molecule {
atomic {
𝑠1
}
⇋
atomic {
𝑠1 ′
}
⊗
atomic {
𝑠2
}
⇋
atomic {
𝑠2 ′
}
}
Rigorous Software Engineering
Microsoft Research, India
Account transfer with MT
let transfer from to amount =
molecule {
do! atomic {
match hasBalance from amount with
| true -> debit from amount
| false -> abort
}
|> compensateWith <|
atomic { credit from amount }
return! atomic {
match exists to with
| true -> credit to amount
| false -> abort
}
}
Rigorous Software Engineering
Microsoft Research, India
Hides
•
•
•
First atomic step
Serialization
Messaging
Fault tolerance
Compensation
No isolation
•
Compensating
Secondmust
atomic
actions
step undo
semantically
Implementation
Rigorous Software Engineering
Microsoft Research, India
System model
• Compute agents
– May fail at any time
– System detects failure and restarts agents
– All agent-local state is lost
• Partitioned storage
– Partitions are units of serializability
• Persistent queue
– Communication between agents
Rigorous Software Engineering
Microsoft Research, India
Persistent queue
• Not really a queue!
– Out-of-order
– At-least once
• Operations
– Enqueue(m)
– Get()
• Gets a message, makes message invisible
• Message re-appears if not dequeued
– Dequeue(m)
• Permenantly deletes the message
Rigorous Software Engineering
Microsoft Research, India
Tolerating agent failures
• Agent can fail between transactions
• Check-pointing
– Check-point state after every transaction
Rigorous Software Engineering
Microsoft Research, India
Check-pointing
𝑎1 ⊗ 𝑎2 ⊗ 𝑎3
𝑎3
Enqueue
𝑎1
Read
𝑎2 ⊗ 𝑎3
𝑎2
𝑎 2 ⊗ 𝑎3
Dequeue
Database
partition
Database
partition
Rigorous Software Engineering
Microsoft Research, India
Compute failures
𝑚′
Enqueue
Read
• Transactions may be
evaluated more than
once!
• Messages may be
sent more than
once!
𝑎
𝑚
Dequeue
Rigorous Software Engineering
Microsoft Research, India
Database
partition
Idempotence
• Instrument transactions for idempotence
– Assumes key-value store with a unique key
constraint
– Assign each atomic step in each MT a unique id
– Add (unique id, return value) to write set
– Idempotence log in transaction’s partition
• If transaction evaluates more than once
– Unique key violation causes transaction failure
– Return stored value
Rigorous Software Engineering
Microsoft Research, India
Summary
• Molecular transactions
– Language abstraction for programming weakly
consistent applications
– Hides messaging, queuing, fault tolerance
– Expressed using a monad, lends to declarative,
bug-free code
• Efficient implementation on cloud based
storage systems
– Does not require 2PC!
– Built a number of applications on Azure
– < 10% overheads over hand-written code
Rigorous Software Engineering
Microsoft Research, India
Open questions
• Specifying and reasoning about correctness
of molecular transactions
• Declarative ways of making
consistency/performance trade-offs
• Do cloud-based systems provide right
primitives?
Rigorous Software Engineering
Microsoft Research, India
Thank you
Questions?
Rigorous Software Engineering
Microsoft Research, India