High per­for­mance JMS pro­cess­ing with XA

Ex­act­ly-once is pos­si­ble at high speed!

How do you process JMS mes­sages with high­er per­for­mance? With XA!

With the clas­si­cal ar­gu­ment against XA be­ing per­for­mance, most of you will prob­a­bly find this post strange.

How­ev­er, we've been able to do this - by ex­ploit­ing some tech­ni­cal ca­pa­bil­i­ties of XA and dis­trib­uted trans­ac­tions!

That's right: with XA we can de­lay the com­mit un­til af­ter a batch of mes­sages is processed (and also af­ter the cor­re­spond­ing data­base up­dates were done). This means that we re­duce the num­ber of synced I/O writes (at com­mit time) to a frac­tion of what would oth­er­wise be need­ed. This can make a big dif­fer­ence in per­for­mance.

Best of all, our batch­ing is smart so it can dy­nam­i­cal­ly ad­just if there are er­rors in the batch. Oh, and did we men­tion it guar­an­tees ex­act­ly-once pro­cess­ing?

Sum­ma­ry

• we en­able ex­act­ly-once pro­cess­ing
• at high speed

Now who could pos­si­bly want that? If you know any­body, feel free to for­ward this blog post to them

In­ter­est­ed in learn­ing more? Con­tact us for a free tri­al!

Free Tr­i­al