MicroTx Enterprise Edition Features

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.

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.

Summary

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.

Source: oracle.com