Guar­an­teed or­der of up­dates is claimed to be hard in dis­trib­uted sys­tems. It's not - if you read this…

The Prob­lem

Sup­pose you want to ap­ply up­dates in the same or­der across dif­fer­ent parts of a dis­trib­uted sys­tem. For in­stance, per­haps you want to keep 2 in­ven­to­ry data­base repli­cas in-sync with Trans­ac­tion­sEssen­tials. Now imag­ine two dis­trib­uted (JTA/XA) trans­ac­tions T1 and T2, each up­dat­ing the two repli­cas of the in­ven­to­ry of the same prod­uct P:

• T1 wants to up­date both repli­cas to set the stock of P to 3, and
• T2 wants to up­date both repli­cas to set the stock of P to 2

If T1 and T2 up­date each data­base in a dif­fer­ent or­der, then the in­ven­to­ry of P would end up be­ing 2 in one repli­ca, and 3 in the oth­er. Now they are not repli­cas any more... So can we avoid that? Yes, we can! Read on to learn how...

Order-Pre­serv­ing Writes With JDBC

First, let's take the case of a prim­i­tive ap­pli­ca­tion that up­dates the two data­bas­es di­rect­ly (via JDBC):

The Ap­pli­ca­tion

We're as­sum­ing that the ap­pli­ca­tion is a trans­ac­tion­al Java ap­pli­ca­tion that uses the Atomikos trans­ac­tion man­ag­er. It's the ap­pli­ca­tion that takes care of the repli­ca­tion (con­trast this to DBMS-in­ter­nal repli­ca­tion which is not even re­quired here).

DBMS 1

The first repli­ca data­base. We as­sume that this data­base uses lock­ing to pro­tect the data from con­cur­rent trans­ac­tions.

DBMS 2

The sec­ond repli­ca data­base. We as­sume that this data­base uses lock­ing to pro­tect the data from con­cur­rent trans­ac­tions.

The So­lu­tion

The so­lu­tion is pret­ty sim­ple:

• If both DBMS use lock­ing, and
• If both trans­ac­tions T1 and T2 use two-phase com­mit as per Trans­ac­tion­sEssen­tials

... then the or­der of the writes is guar­an­teed to be the same at both data­bas­es. Now, how much sim­pler can it get?

Order-Pre­serv­ing Writes With Mi­croser­vices (REST or SOAP)

So what if we want to have mi­croser­vices in­stead? That's no prob­lem, but you'll need Ex­tremeTrans­ac­tions to do the same thing across mi­croser­vices.

The Ap­pli­ca­tion

Now the ap­pli­ca­tion is a trans­ac­tion­al Java ap­pli­ca­tion that uses Ex­tremeTrans­ac­tions. Once again, it's the ap­pli­ca­tion that takes care of the repli­ca­tion - but this time by call­ing two mi­croser­vices:

Mi­croser­vice 1

This ser­vice man­ages the first repli­ca data­base. We as­sume that the data­base uses lock­ing to pro­tect the data from con­cur­rent trans­ac­tions.

Mi­croser­vice 2

This ser­vice man­ages the sec­ond repli­ca data­base. We as­sume that the data­base uses lock­ing to pro­tect the data from con­cur­rent trans­ac­tions.

The So­lu­tion

The so­lu­tion is ex­act­ly the same as in the pre­vi­ous case, but the ap­pli­ca­tion and each mi­croser­vice need to use Ex­tremeTrans­ac­tions so every­thing is part of one and the same dis­trib­uted trans­ac­tion.

Why Does This Work?

The rea­son that this works is thanks to the com­bi­na­tion of lock­ing and two-phase com­mit. The log­ic re­lies on two spe­cif­ic be­hav­iour­al prop­er­ties:

1. The or­der of the up­dates by T1 and/or T2 in each DBMS cor­re­sponds to the or­der of lock ac­qui­si­tion by T1 and/or T2.
2. In ei­ther DBMS, T1 can only ac­quire a lock on P af­ter T2 com­mits (or vice ver­sa, whichev­er trans­ac­tion gets a lock first).
3. Either trans­ac­tion will only com­mit af­ter it has ac­quired all its locks on P (mean­ing, a lock on P in both data­bas­es).

The proof is by con­trac­tion: sup­posed that T1 up­dates first in DBMS 1 and T2 up­dates first in DBMS 2. That would im­ply that:

• T1 com­mits be­fore T2 in DBMS 1, which by (3) would im­ply that T1 has got­ten all its locks first in both DBMS.
• T2 com­mits be­fore T1 in DBMS 2, which by (3) would im­ply that T2 has got­ten all its locks first in both DBMS.

Con­clu­sion: both can­not be true at the same time, so it is im­pos­si­ble for the or­der of up­dates to be dif­fer­ent in ei­ther DBMS.

It should be easy to see how this can be gen­er­alised to non-repli­ca sce­nar­ios. The locks don't need to be on repli­cat­ed items, they can be on any item con­cur­rent­ly ac­cessed by ei­ther trans­ac­tion and the same con­clu­sion would hold.

By the way, a very nice prop­er­ty of this so­lu­tion is that this works re­gard­less in what or­der T1 and T2 are try­ing to ac­cess ei­ther ser­vice or data­base. The DBMS lock man­ag­er will take care of that...

Pit­fall

The proof does not hold if locks are re­leased be­fore com­mit time. This should not be a prob­lem since usu­al­ly, locks are not re­leased be­fore com­mit.

Ver­i­fi­ca­tion of this is left as an ex­er­cise to the read­er.

What about dead­locks?

Some crit­ics will claim that dis­trib­uted trans­ac­tions cause dead­locks. That's pos­si­ble, but at least dis­trib­uted trans­ac­tions will break dead­locks af­ter a time­out. You can al­ways have dead­locks even if us­ing only one data­base, and (what's worse) with­out dis­trib­uted trans­ac­tions there will typ­i­cal­ly be NO time­out for those.

This also works for ex­act­ly-once de­liv­ery

Ac­tu­al­ly, this so­lu­tion also works for ex­act­ly-once de­liv­ery - which is re­al­ly cool don't you think?

Ready to Try? Ap­ply here for a free tri­al of Ex­tremeTrans­ac­tions

Trust­ed By