MicroTx Enterprise Edition Features

January 19, 2024 | 5 minute read
Todd Little
Chief Architect, Transaction Processing Products
Text Size 100%:

Oracle recently announced the availability of MicroTx Enterprise Edition.  This new release adds many new enterprise features making MicroTx Enterprise Edition suitable for a wide variety of enterprise applications.  This blog post will go into the details of these new features.

No Limit on Transaction Throughput

One of the most important changes in the MicroTx Enterprise Edition is the elimination of the transaction throughput limit.  MicroTx Free only allows 4,800 transactions per hour as it is intended for development and not production or enterprise deployments.  With the release of MicroTx Enterprise Edition, this limitation no longer exists and MicroTx Enterprise Edition deployments can handle hundreds to thousands of transactions per second.  This level of throughput exceeds the requirements of almost all applications.  To put transaction volumes in perspective, Visa claims to have processed 276 billion transactions in the 12 months ending in September 30, 2023, which works out to an average of 8,700 transactions per second.

Admin Console

Enterprise users need a way to monitor and manage their distributed transactions.  With the new administration console added to MicroTx Enterprise Edition, users can observe what transactions are in flight, performance metrics for the coordinator cluster, commit/rollback transactions with heuristic outcomes, and more.

MicroTx Enterprise Edition Console

Transaction Coordinator Clusters

For enterprise users, this release of MicroTx Enterprise Edition provides greatly improved reliability, availability, scalability, and performance (RASP) features. Much of this comes from a couple of key features including the ability to run multiple copies of the MicroTx Enterprise Edition transaction coordinator as part of a cluster.  This allows MicroTx Enterprise Edition to scale out and scale in to meet the demands of your application.  Should you need more transaction throughput, you can simply increase the number of replicas of the MicroTx Enterprise Edition transaction coordinator. 

For the clustering support to improve performance, the service mesh to which MicroTx Enterprise Edition is deployed must support request affinity.  This means that requests from an initiator and the other participants in a transaction will land on the same transaction coordinator instance.  This is typically provided by the service mesh by hashing some HTTP header and using that hash to determine which transaction coordinator instance the request should be delivered to.  This also allows the transaction coordinator to cache transaction state in memory as all related requests will usually end up on the same instance.  Should a request, as part of a transaction, land on a different instance due to failure or scaling operations, that instance can recover the transaction state from the persistent transaction state maintained in etcd or Oracle Database.

Persistent Transaction State

To ensure transactions can be properly handled in the presence of failures, the state of the transaction needs to be persisted in case a transaction coordinator fails.  MicroTx Enterprise Edition supports persisting transaction state to either etcd or Oracle Database.   Either can be used just by setting the appropriate configuration information.

By storing the transaction state in a shared persistent store, the MicroTx Enterprise Edition transaction coordinator can recover from a variety of failures.  Should a coordinator instance fail, another transaction coordinator can take over handling any inflight transactions being processed by the failed coordinator.  Whether that failure is a crash, network failure, operator error, or pretty much any other reason, subsequent requests will be handled by one of the remaining transaction coordinator instances.  This ensures transactions can be successfully processed even amid most failures.  There are always some failures that can cause a heuristic outcome, such as a database prematurely committing or rolling back its portion of a transaction.

RAC Support for XA Transactions

Oracle RAC databases require that transaction branches not span RAC instances.  This means a transaction manager must be aware of the RAC instance participants are using, or use singleton database services that are only active on one RAC instance at a time.  MicroTx Enterprise Edition handles this by having the RAC instance ID reported to the transaction coordinator when a participant microservice enlists in a transaction.  This allows the coordinator to determine if a new transaction branch is required or not.  Without this capability, microservices using a RAC database would have to use singleton database services.

Common XID

In the XA pattern for distributed transactions, each transaction branch needs to be prepared and committed.  More branches equates to more messages that need to be sent when committing the transaction.  To help prevent the proliferation of transaction branches, MicroTx Enterprise Edition will try to reuse branches if possible.  It does this by having the participants report what resource manager they’re using when they enlist in the transaction.  The coordinator uses this information to decide if a new transaction branch needs to be created.  If there is already an existing transaction branch in the resource manager, the coordinator will return the same XID (global transaction identifier and branch qualifier), thus eliminating the need for another branch.  If this is the first time the resource manager is being enlisted in the transaction, the coordinator will return a new unique branch qualifier.  In the case where all participants are using the same resource manager such as Oracle database, the transaction will be committed one phase saving a lot of messages and eliminating the need for the coordinator to write to its transaction log.  This can result in dramatic performance improvements.

XA Transaction Promotion

When starting an XA transaction, if enabled, MicroTx Enterprise Edition will actually start a local transaction.  The transaction will remain a local transaction until such time as another participant may become involved in the transaction.  At that point, MicroTx Enterprise Edition will promote the local transaction to a full XA transaction.  This makes the cost of starting a transaction minimal until such time it may need to be promoted.  Currently the decision to promote occurs whenever a call is made to another microservice.  At that point MicroTx Enterprise Edition promotes the transaction even though the called microservice may not end up being a participant.This currently only works with Oracle database.

Grafana Dashboard

Included in the MicroTx Enterprise Edition release are Grafana dashboards.  The MicroTx Enterprise Edition coordinator provides metrics that can be collected by Prometheus and visualized using Grafana as shown in this picture.

MicroTx Grafana dashboard


This new Enterprise Edition of MicroTx provides all the features, performance, and resiliency required for enterprise applications.  Developer should feel comfortable relying on MicroTx Enterprise Edition to help address their data consistency requirements in microservice based applications.  Start with MicroTx Free while developing and testing your microservices, and then switch to MicroTx Enterprise Edition when it comes time to move to production.


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

Customizing risk assessment in Oracle Data Safe

Pedro Lopes | 4 min read

Next Post

Accelerate innovation with enterprise data, OCI Generative AI, and enhanced security

Marty Gubar | 3 min read