Queued Transactions

Persistent queues provide the basis for queued transactions. This example illustrates an atomic transfer of money between accounts in different banks even though all transactions are local (there are no distributed transactions).

Bank C has a local database containing

• Persistent message queue Q₁ holding messages to be delivered to Bank A; and
• Persistent message queue Q₂ holding messages to be delivered to Bank B.

Bank A has a local database containing

• An integer N_Q1 which records the number of messages which have been processed so far from Q₁; and
• The balance A₁ on an account managed by bank A

Bank B has a local database containing

• An integer N_Q2 which records the number of messages which have been processed so far from Q₂; and
• The balance A₂ on an account managed by bank B

Initially suppose N_Q1 = N_Q2 = 0 and A₁ = A₁ = $100.

Bank C wants to transfer $10 from account A₁ to account A₂. This is achieved with an atomic transaction on its local database:

• Insert message to deduct $10 from account A₁ into Q₁; and
• Insert message to add $10 to account A₂ into Q₂.

Some time later bank A receives the message to deduct $10 from account A₁. Bank A then applies an atomic transaction on its local database:

• N_Q1 = 1 and
• A₁ = $90

Some time later bank B receives the message to add $10 to account A₂. Bank B then applies a atomic transaction on its local database:

• N_Q2 = 1 and
• A₂ = $110

It is possible to avoid a negative balance: Introduce two holding accounts A₃,A₄ on C. C transfers A₁ to local A₃. A transfers from A₃ to A₄. When C finds money in A₄ it transfers to A₂.

ATMs are designed to have a normal case behaviour and a partition mode behaviour. In partition mode availability is chosen over consistency. The issue is you might withdraw more money than you have so the end result might be consistent, but negative, which can’t be compensated for by asking for the money back, so instead, the bank will change you an overdraft penalty.