Distrib­uted Trans­ac­tion Pat­terns

This tech tip ex­plores some pat­terns for dis­trib­uted trans­ac­tions.

Sup­pose you have two process­es (A and B) on two dif­fer­ent ma­chines. How can you en­sure re­li­a­bil­i­ty of tasks that span these two process­es? In oth­er words: how can you make sure that there is no par­tial work done by A (but not by B) or the oth­er way around. Depend­ing on what you want and the na­ture of your ap­pli­ca­tion, there are dif­fer­ent ways of do­ing this. This tech tip ex­plains the most com­mon so­lu­tions.

SOLUTION 1: Re­quest/re­ply with trans­ac­tion prop­a­ga­tion

This so­lu­tion ap­plies to HTTP/REST or web ser­vice (SOAP) sce­nar­ios.

In this ap­proach, you would do the fol­low­ing:

• Use Trans­ac­tions in each process.
• A starts a trans­ac­tion be­fore call­ing B.
• Pro­cess A ships the prop­a­ga­tion of the trans­ac­tion along with each re­mote call to B.
• B im­ports the trans­ac­tion be­fore pro­cess­ing the call.
• B process­es the call.
• B ter­mi­nates the im­port­ed trans­ac­tion and re­turns the Ex­tent to A.
• A adds the ex­tent to its lo­cal trans­ac­tion.
• A in­structs com­mit or roll­back of the dis­trib­uted trans­ac­tion.

This en­sures that both A and B ei­ther com­mit or roll­back the same way.

Another ap­proach would be to use JMS, as ex­plained next.

SOLUTION 2: JMS with XA dri­vers

In this ap­proach, the calls from A to B are done by JMS mes­sages. This is done as ex­plained be­low.

To send a mes­sage to B, A does the fol­low­ing:

• A starts a trans­ac­tion.
• A sends a JMS mes­sage to B, and uses XA JMS dri­vers to do so.
• A com­mits the trans­ac­tion.

On the oth­er side, B re­ceives a mes­sage as fol­lows:

• B starts a trans­ac­tion (or uses the Atomikos JMS ses­sion to do this au­to­mat­i­cal­ly).
• B con­sumes the JMS mes­sage.
• B com­mits the trans­ac­tion (or lets the Atomikos JMS ses­sion do this).

This pat­tern also en­sures re­li­a­bil­i­ty, but should be used only un­der the fol­low­ing con­di­tions:

• The JMS is used in per­sis­tent mode.
• A de­lay is ac­cept­able be­tween pro­cess­ing at A and pro­cess­ing at B.
• When A sends the mes­sage to B, it is al­ready cer­tain that the mes­sage can be processed at B.
• A does not ex­pect a re­ply from B be­fore com­mit­ting its trans­ac­tion.

The first con­di­tion is re­quired to avoid mes­sage loss af­ter A com­mits. The sec­ond con­di­tion is need­ed be­cause JMS is asyn­chro­nous in na­ture. The third con­di­tion en­sures that B will even­tu­al­ly be able to process the mes­sage. The fourth con­di­tion is due to the fact that JMS can't re­ceive a re­ply to a mes­sage that is sent with­in the same trans­ac­tion.

For shared data­base sit­u­a­tions be­tween A and B: make sure to send (from A to B) via a dif­fer­ent AtomikosCon­nec­tionFac­to­ryBean, or (al­ter­na­tive­ly) make sure to send to B in a sub­trans­ac­tion. Other­wise, B might re­ceive the mes­sage be­fore A's data­base up­dates are com­mit­ted... Also see Doc­u­men­ta­tion.Com­mitOrder­ingWithJms for de­tails.

SOLUTION 3: JMS with trans­ac­tion prop­a­ga­tion

This ap­proach works sim­i­lar to the first (re­mot­ing) ap­proach, ex­cept that JMS mes­sages are used in­stead of HTTP/SOAP calls. In this case, the JMS mes­sages can be ei­ther per­sis­tent or non-per­sis­tent, and the ac­knowl­edge­ment mode should NOT be trans­ac­tion­al (mean­ing that non-XA, reg­u­lar JMS dri­vers should be used and mes­sages should be sent with ei­ther AUTO ACKNOWLEDGE or EXPLICIT ACKNOWLEDGE set­tings. If this is true then the fol­low­ing will work:

• Use Trans­ac­tions in each process.
• A starts a trans­ac­tion be­fore send­ing a mes­sage to B.
• Pro­cess A ships the prop­a­ga­tion of the trans­ac­tion along with each JMS mes­sage to B.
• B im­ports the trans­ac­tion be­fore pro­cess­ing the mes­sage.
• B process­es the mes­sage.
• B ter­mi­nates the im­port­ed trans­ac­tion and re­turns the Ex­tent to A in a re­ply mes­sage.
• A adds the ex­tent to its lo­cal trans­ac­tion.
• A in­structs com­mit or roll­back of the dis­trib­uted trans­ac­tion.

SOLUTION 4: TCC

TCC is the most loose­ly-cou­pled so­lu­tion with vir­tu­al­ly guar­an­teed op­er­abil­i­ty for Ser­vice Ori­ent­ed Ar­chi­tec­tures. If you want to know more then check­out Trans­ac­tions for SOA.

Try for your­self

All of the pat­terns de­scribed here are part of our com­mer­cial prod­uct suite. Start a free tri­al by click­ing the but­ton be­low:

Free Tr­i­al