Oracle continues to show its commitment to microservices for enterprise customers with a new release of MicroTx. This release contains features requested by customers to solve their consistency issues in a microservice based application. In particular it includes several features for customers using XA transactions to ensure strong data consistency across microservices. This post will go into the details of those new features.
Not all resource managers such as databases or messaging systems provide support for XA transactions. Microservices that need to use a non-XA compliant resource manager may need to have their resource manager included in an XA distributed transaction. The Last Resource Commit (LRC) optimization allows one non-XA compliant resource manager to be included in an XA transaction, with some limitations. This optimization is very similar to the Logging Last Resource (LLR) Transaction optimization with one difference. In LLR, the transaction coordinator asks the LLR participant to store the transaction commit record. This requires the MicroTx client library to understand how to store data in the LLR resource such as MongoDB. In some cases, it's not feasible to store the commit record in the non-XA compliant resource manager so another approach is needed. This is where LRC comes into play. With LRC, the transaction coordinator prepares all XA participants, and then asks the LRC participant to commit its local transaction. The outcome of that local commit request determines the outcome of the transaction. If the LRC local commit fails, then the transaction coordinator will tell all the prepared XA participants to rollback. If the outcome of the LRC local commit is success, then the transaction coordinator will tell all the prepared XA participants to commit.
The major drawback to using LRC over LLR or an XA resource is that it increases the possibility of a heuristic outcome. A hueristic outcome is when some participants commit and others rollback or the outcome for one or more participants is unknown. Virtually all distributed transaction models can have heuristic outcomes, but XA in general minimizes these through the two phase commit protocol. In LRC, a heuristic outcome can occur if the LRC resource commits its local transaction successfully, but some failure prevents the transaction coordinator from getting the success response. This leads the transaction coordinator to incorrectly believe the commit request failed and proceed to rollback all of the prepared XA participants.
Typically microservices only use a single resource manager to store any necessary persistent state. However there are times when it is useful to have a single microservice use more than one resource manager. A simple example of this is a microservice that wants to remove a message from a queue and perform some database operations. Another example as shown below is needing to use two different databases such as Oracle Database and PostgreSQL. The application uses connections injected by the MicroTx client library:
/** * The Database Connection injected by the TMM Library. Use this connection object to execute SQLs (DMLs) within the application code. */ @Inject @TrmSQLConnection(name = "departmentDataSource") private Connection connection; @Inject @TrmSQLConnection(name = "creditDataSource") private Connection creditConnection;
The connections are defined in the application,yaml
#Modify the below to provide database connection details for your database departmentDataSource: url : "jdbc:oracle:thin:@tcps://XXXXwallet_location=Database_Wallet" user: "XXXX" password: "XXXXX" rmid : "4F58D282-0DE1-453C-B872-291FDBF49CFF" creditDataSource: url: "jdbc:postgresql://<link>:<port>/<database>" user: "XXXX" password: "XXXX" rmid : "4F58D282-0DE1-453C-B872-291FDBF49CGG"
This allows the use of both an Oracle Database connection and a PostgreSQL database connection in the same microservice in the same transaction.
This new release includes support for using the Try-Confirm/Cancel (TCC) transaction protocol in Python applications built using either Flask or Django. Like other language support for TCC, your application code must provide REST endpoints for:
New participants in the TCC transaction are added using the TCCConfig.addTccParticipant(URI) method.
At times it may be helpful for a transaction participant to get notified before the transaction coordinator begins the prepare phase of an XA transaction and after the commit/rollback phase. A common use case for this is to allow flushing data cached in memory to a database. A participant that has read some data from a resource manager, modified that data in memory, and is now ready for the transaction to complete. As the data hasn't yet been updated in the resource manager, the participant needs to update the resource manager before the transaction can be committed. By registering for the beforeCompletion event, the participant will receive a callback from the transaction coordinator prior to it beginning the prepare phase. This allows the participant to persist the updated data in memory to the associated resource manager. A participant may also need to clean up things in memory after the commit/rollback, so it can register for a afterCompletion event and get called back once the transaction has committed or rolled back.
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. 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 more than 40 years of software architecture and development experience, I have worked on a wide range of software systems and technology. 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.