Announcing Oracle Transaction Manager for Microservices 22.3.1

Oracle is pleased to announce a new release of Oracle Transaction Manager for Microservices Free (MicroTx).  This new release, 22.3.1, provides a number of enterprise enhancements and demonstrates Oracle's commitment to microservices.

Enhancing Transaction Coordinator Availability, Scalability, and Recoverability

This new release includes a number of resiliency enhancements that improve the availability, scalability, and recoverability of the MicroTx transaction coordinator microservice.  With this new release, the MicroTx transaction coordinator microservice tcs can be configured to store transaction records in either Oracle Database or etcd in place of the current in memory transaction log.  This allows tcs to recover inflight transactions should the tcs instance fail.   More importantly this allows for deploying multiple tcs instances as part of a cluster sharing the transaction logs stored in Oracle Database or etcd.  By being able to cluster this microservice, you can scale up and down the number of tcs instances needed for load and availability.

Session Affinity

Often customers will want to run multiple instances of their microservices.  When one of these instances enlists in an XA transaction, it provides a callback URL that tcs can use to manage the transaction.  Typically this URL is common across all the instances of the microservice.  When tcs calls back to a participant microservice using XA, the request will get routed to whatever tcs instance the service mesh decides.  There are several use cases where tcs needs to call back to the same instance that enlisted in the transaction.  Here are just some of the reasons when session affinity is required:

1. The participant is a Last Logging Resource (LLR) participant in an XA transaction.  For LLR, the MicroTx transaction coordinator prepares all the other participants, and then sends a commit request to the LLR participant with a copy of the commit record.  That commit record is written to the LLR's resource manager as part of the local resource manager transaction, and then the participant commits the local resource manager transaction that includes any resource manager updates made by the participant.
2. The participant is using PostgreSQL as its resource manager.  The issue here is that XA call backs made by the MicroTx coordinator, must go to the same participant instance that was enlisted in the transaction as PostgreSQL requires those operations be performed on the same connection as was used when participating in the XA transaction.
3. The participant in a MicroTx transaction is holding state that is not shared across instances of the participant.  By using session affinity, it can be assured that the requests associated with a specific transaction get routed to the same instances.

Session affinity can be enabled on a per participant level.  Unless session affinity is required, it's recommended to not enable it

Resource Manager ID (RMID)

In the initial release of MicroTx, participant microservices were required to define a unique resource manager ID or RMID identifying the resource manager the microservice was using.  The purpose of this configuration item is to allow the MicroTx transaction coordinator to perform some optimizations for XA transactions.  In particular, in this release, the RMID is optional, but providing it correctly can help improve application performance.  When a participant microservice enlists in an XA transaction, it provides the RMID, if configured, in the enlistment request.  The MicroTx transaction coordinator uses this information to determine whether a new transaction branch needs to be created or not for this enlistment.  If another participant has already enlisted in the XA transaction with the same RMID, the new enlistment will receive the same XID, including the same branch qualifier as the other participant.  This reduces the number of branches in the XA transaction which reduces the time to commit the transaction, increasing the performance of the application.  In some cases where all the participant microservices are using the same resource manager such as Oracle Database, the transaction can end up being committed with a one phase commit, skipping the prepare phase and further increasing the performance of the application.

Summary

Oracle continues its commitment to developers creating microservices and helping them ensure consistency across those microservices.  With this new release's focus on reliability, available, scalability, and performance, customers can comfortably use distributed transactions in their production environments.  Stay tuned for more enhancements coming up for Oracle Transaction Manager for Microservices.