New Release of MicroTx 22.3.2

Announcing Oracle Transaction Manager for Microservices (MicroTx) 22.3.2

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.

Last Resource Commit Optimization for XA Transactions

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.

Microservice Participants Using Multiple Resource Managers

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.

Python Support for Try-Confirm/Cancel

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:

◉ Making a reservation using POST

◉ Confirming a reservation using PUT

◉ Deleting a reservation using DELETE

New participants in the TCC transaction are added using the TCCConfig.addTccParticipant(URI) method.

Transaction Event Notifications

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.

Source: oracle.com