Where is the Complexity? Part 4

May 10, 2024 | 3 minute read
Todd Little
Chief Architect, Transaction Processing Products
Text Size 100%:

In my previous post, I pointed out the simplicity of using XA transactions. However I used a diagram that made it appear XA was more complex.  While it's true that XA is more complex than ignoring data consistency, the complexity is in the XA infrastructure and transaction coodinator and not in the developer's code.  The key is that XA makes the developers life simpler by ensuring ACID data consistency without and application provided logic beyond demarcating the transactions boundaries.  The consistency is immediate, guaranteed, and with complete isolation which sagas give up and allow dirty reads. 

Dirty Reads

Dirty reads can lead to data inconstency as a decision may be made on stale data.  A classic example of this occurs when you have 2 overlapping sagas.  The first saga S1 deposit $100 into an account, but has not yet closed/finalized the saga.  The second saga S2 withdraws that $100 and closes/finalizes.  For some reason the first saga S1 ends up needing to be compensated, so its compensation logic tries to withdraw the $100 originally deposited.  However due to the dirty read made by S2, S1 may not be able to compensate as there may no longer be $100 to withdraw.  In sagas, this issue is typically pushed on to the developer as is seen in my second post in this series.  In that post, we can see that S1 doesn't actually update the account balance as part of the deposit request, but instead that amount is effectively placed in escrow by keeping the amount in the journal until the saga completes.  This may not seem very complex, but this is also a trivial example and already one can see the complexity being pushed on to the developer by using sagas.

Purist vs Pragmatist

The microservice purist will claim that every service should have its own database, and that there should be no coupling between services such as introduced by a distributed transaction.  Likewise a data consistency purist (if there is such a term) will claim that ACID is the only acceptable solution and that isolation is absolutely necessary.  A pragmatist would say that both of those positions are extremes and trade-offs must be made.  In real life there aren't many one size fits all solutions except maybe for scarves and headbands, and the same is true with software architectures.  Usually the best solution is somewhere between the extremes or at least a mix of the extremes. So how do you find that mix or make those trade-offs?

Making Trade-offs

It's key to understand why you choose a specific solution to dealing with the issue of data consistency.  Choosing sagas simply because you're a microservice purist ignores the real world issues of adopting an eventual consistency pattern.  Likewise choosing strong consistency via ACID simply because you're a data purist makes little sense.  One must examine what trade-offs are being made in choosing one over the other and the same decision doesn't need to be made for all of your microservices.  One of most common examples of when it really makes sense to use a saga is when the data that needs to be updated consistently is in flux for a relatively long period of time such as waiting for user input.  While one could use ACID transactions such as XA, it's generally not recommended due to the increased potential for lock contention.  However if you're designing an application that requires immediate consistency, it's hard to beat XA, especially considering how easy it is to use.

Sagas, Escrow, and Oracle Database

In an upcoming post I'll describe how Oracle Database sagas, externally managed by MicroTx, can automatically handle the escrowing of the funds using RESERVABLE columns.  RESERVABLE columns can allow multiple transactions to update a row concurrently by not locking the row.  I'll get into the details of how that works in a future post.

For more information on MicroTx, please visit https://www.oracle.com/database/transaction-manager-for-microservices

Todd Little

Chief Architect, Transaction Processing Products

I'm currently the Chief Architect for a family of transaction processing products at Oracle including Oracle Tuxedo product family, Oracle Blockchain Platform, and the new Oracle Transaction Manager for Microservices (MicroTx).  My main areas of focus are on security, privacy, confidentiality, performance, and scalability.  My job is to provide the technical strategy for these products to ensure they meet customer requirements.

Prior to being acquired by Oracle, I was Chief Architect for BEA Tuxedo at BEA Systems, Inc. While at BEA Systems, I was responsible for defining the technical strategy and direction for the Tuxedo product family. I developed the Tuxedo Control for WebLogic Workshop that greatly simplified the usage of Tuxedo services from Workshop based applications. I also received two patents for methods allowing design patterns in a UML modeling tool to control the generation of software artifacts.

During my nearly 50 years of software architecture and development experience, I have worked on a wide range of software systems and technology and have 44 published patents. At Science Applications International I worked on microcoded plasma display systems and command, control, and communication systems for naval applications. As a senior software consultant at Digital Equipment Corporation, I was the New York Area Regional Tools Consultant and also helped develop a multi-language multi-threaded distributed object oriented runtime environment with concurrent garbage collection.


Previous Post

Autonomous Health Framework (AHF) Version 24.4 Released

Gareth Chapman | 7 min read

Next Post


Oracle Globally Distributed Database addresses multi-country data residency challenges for Munich Re HealthTech

Deeksha Sehgal | 8 min read