Molecular Transactions G. Ramalingam Kapil Vaswani Rigorous Software Engineering, MSRI.

Molecular Transactions

G. RamalingamKapil Vaswani

Rigorous Software Engineering, MSRI

Simple banking application

Rigorous Software EngineeringMicrosoft Research, India

let transfer from to amount =atomic {

match hasBalance from amount with

| true -> debit from amountcredit to amountSUCCESS| false ->

INSUFFICIENT_BALANCE}

Applicationserver

Database

Account#

Name Balance

XXXX0123 ABC 10000

XXXX3452 XYZ 20000

ACID Transaction


?

Scalable applications

• Support lots of users– TBs of data!– Many concurrent transactions– Unpredictable workload

• Key requirements– Available– Fault tolerant– Data consistency

• Achieving all at the same time non-trivial!


Applicationserver

RelationalDatabase

Rigorous Software Engineering Microsoft Research, India

Designing for scale


Scaling application tier

Applicationserver

Database


Replication

Applicationserver

Replica Replica Replica


Data partitioning

Applicationserver

Datapartition

Datapartition

A first-class citizen in cloud based storage systems

Horizontal data partitioning


let transfer from to amount =let status = atomic {match hasBalance from amount with| true -> debit from amountDEBIT_COMPLETE| false -> INSUFFICIENT_BALANCE}

atomic {match status with| DEBIT_COMPLETE ->

credit to amount

SUCESSS| _ ->


Databasepartition

Databasepartition

Branch Account#

Name Balance

XXXX01 XXXX0123

ABC 10000

Branch Account#

Name Balance

XXXX34 XXXX3452

XYZ 20000

Distributed transactions do not scale

Azure tables, BigTable, Dynamo do not support distributed transactions!

Distributed vs. local transactions

Consistency


let transfer from to amount =let status =

atomic {match hasBalance from amount with| true -> debit from amountDEBIT_COMPLETE| false -> INSUFFICIENT_BALANCE}


credit to amount

SUCESSS| _ ->


Databasepartition

Databasepartition

Account#

Name Balance

XXXX0123 ABC 5000

Account#

Name Balance

XXXX3452 XYZ 20000


Compute failures



Databasepartition

Databasepartition

Account#

Name Balance

XXXX0123 ABC 5000

Account#

Name Balance

XXXX3452 XYZ 20000

Server failures

Handling compute failures



Databasepartition

Databasepartition

Account#

Name Balance

XXXX0123 ABC 5000

Account#

Name Balance

XXXX3452 XYZ 20000


credit to amount

SUCESSS| _ ->


Checkpointstorage

There’s more…logical failures



Databasepartition

Databasepartition

Account#

Name Balance

XXXX0123 ABC 5000

Account#

Name Balance

XXXX3452

XYZ 20000

What if credit fails?

e.g. account closed

Handling logical failures withcompensating actions



Credit fails

let compensate from amount =atomic {

credit from amount}

Molecular transactionsFault-tolerant composition of atomic

transactions with compensating actions


atomic {

}

atomic {

}⇋

atomic {

}

atomic {

}⇋

⊗molecule {

}

Account transfer with MTlet 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}

}


First atomic step

Compensation

Second atomic step

Hides • Serialization• Messaging• Fault tolerance

No isolation• Compensating

actions must semantically undo

Implementation


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


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


Tolerating agent failures

• Agent can fail between transactions• Check-pointing– Check-point state after every transaction


Check-pointing


𝑎1

Enqueue Read

Databasepartition

𝑎2

Databasepartition

𝑎3

Dequeue

Compute failures


Read

𝑚𝑎❑

Databasepartition

𝑚 ′

Dequeue

Enqueue

• Transactions may be evaluated more than once!• Messages may be

sent more than once!

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


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


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?


Thank you

Questions?


Molecular Transactions G. Ramalingam Kapil Vaswani Rigorous Software Engineering, MSRI.

Documents

match status

complete false insufficient

true debit

match hasbalance

indialet transfer

complete credit

distributed transactions

namebalancexxxx0 transactions