Oracle and Microsoft expand partnership to deliver Oracle database services in Azure

Organizations want choice, and nearly all of them are using two or more clouds. But, most workloads are still on-premises, and many of them are Oracle Database workloads. Why?

We believe that customers need greater flexibility with best-in-class technologies to move workloads into the cloud. 97% of the Fortune 100 companies rely on Oracle Database for their most critical workloads. Many of these customers have also invested in Microsoft Azure.

Since 2019, we have partnered with Microsoft to deliver the Oracle Interconnect for Azure, which offers secure, private interconnections with sub-2 millisecond latency in 12 global regions. This multicloud network foundation enabled customers, such as AT&T, Marriott International, and Veritas, to build applications across Oracle Cloud Infrastructure (OCI) and Azure.

We’re excited to share that we’re significantly expanding our partnership with Microsoft to launch a new service called Oracle Database@Azure. With this service, Microsoft and Oracle will deliver the same Oracle database services running on OCI in Microsoft Azure datacenters. Oracle database services in Azure are designed to offer high levels of performance, scale, security, and availability — at parity with what we offer in OCI today. By colocating OCI database services in Azure datacenters, we expect that Oracle Database@Azure will have the same low latencies as other Azure services. You can deploy and manage the service through the existing Azure portal and use Azure developer tools, software development kits (SDKs), and APIs.

With this new offering, we’re making it easier for customers to migrate and modernize their Oracle Database workloads to Azure. With Oracle database services running locally in Azure, you can benefit from proximity to familiar application development tools and frameworks to modernize your workloads and run cloud native applications with direct access to data in Oracle Database with the same security and compliance across the entire solution.

Additionally, customers will be able to purchase these services through the Azure Marketplace and apply their purchases to their Microsoft Azure Consumption Commitment (MACC).

Bringing the power of Oracle Autonomous and Exadata to Azure customers

Leading organizations in every industry have long relied on Oracle Exadata and Oracle Real Application Clusters (RAC) to make the most of their data and to power mission critical applications. Oracle Database@Azure brings these technologies into Azure. Oracle RAC allows you to run a single Oracle Database across multiple servers, providing high availability and enabling horizontal scaling for traditional workloads. Building on this scale-out architecture, Oracle Exadata combines high-performance database servers, low-latency interconnects, and intelligent storage with unique, database-aware software optimizations. It can let you access data with less than 20 microseconds of latency, process tens of millions of operations per second, and analyze petabytes of data. Exadata offers the same functionality on-premises and in the cloud, so you don’t have to redesign and rearchitect your applications.

Migrating and deploying production-grade environments is straightforward. Oracle provides proven database migration strategies, including automated migration solutions like Zero-Downtime Migration (ZDM) and powerful tools like Oracle Data Guard and Oracle GoldenGate. Oracle Database@Azure customers will have access to Oracle RAC for high availability using Exadata hardware. The service will be deployable in multiple availability zones to ensure regional high availability and in cross-region pairs to support cross-geography disaster recovery scenarios.

Simplifying purchasing and operations

The deep Azure integration greatly simplifies purchasing and operations in the following ways:

◉ Simplified purchasing: You will be able to purchase Oracle Database@Azure in Azure Marketplace, and those purchases will apply to MACC. You’ll also be eligible for Oracle Support Rewards, a program where you can earn rewards that you can use to reduce your Oracle technology license support bill.

◉ Simplified management: You will be able to manage Oracle databases using native Azure tooling like you would with any other Azure resource.

Figure 1. Oracle Database@Azure home page

◉ Simplified operations: You will be able to use Azure tooling to view all metrics, events, and logs for all Oracle Database@Azure databases.

Oracle and Microsoft are already working with customers, such as PepsiCo, Vodafone, and Voya Financial, to realize this new multicloud reality.

“As a global leader in the financial services industry, Voya has harnessed the power of digital transformation to help provide the best experience for our customers and employees,” said Santhosh Keshavan, executive vice president and chief information officer of Voya Financial, Inc. “As we continue to bring our business applications to the cloud, cloud partnerships have the potential to help the entire industry maintain better security, compliance, and performance, helping to accelerate the development of new technology products, solutions and services that enhance customer experience and help achieve better financial outcomes.”

Source: oracle.com

Continue reading

MicroTx Enterprise Edition is Now Available

Oracle is pleased to announce that the Enterprise Edition of MicroTx previewed at Oracle CloudWorld 2023 is now available for download.  Available as a separate download, MicroTx Enterprise Edition provides the following features above and beyond what is provided in the Free Edition:

1. Clustered Transaction Coordinator – the MicroTx transaction coordinator can now be deployed in a cluster providing high availability and high performance.  The number of replicas of the coordinator can by dynamically scaled out or in as required to achieve the necessary level of performance.
2. Transaction Recovery – the outcome of transactions is durably recorded and recoverable by any member of the transaction coordinator cluster.  This ensures that all participants in a transaction will be notified of their outcome, even if a transaction coordinator instance fails.
3. Transaction Store – the MicroTx transaction coordinator can persist transaction state to either etcd or Oracle Database based upon configuration.
4. Transaction Caching – transaction state information maintained by the coordinators is now cached to improve performance
5. MicroTx Console – an administrative console is provided that allows users and administrators to:
• View in flight transaction information
• View performance and health metrics of the coordinator cluster
• Manage transactions - commit or rollback transactions with heuristic outcomes
• View number of transactions for each transaction pattern that were:
1. Processed
2. Confirmed/Committed
3. Cancelled/Rolledback
4. Completed heuristically
• View configuration of the coordinator
6. RAC Support – participants can now use RAC based databases in XA transactions.  MicroTx tracks which RAC instance participants are using and ensures that a transaction branch doesn’t span RAC instances.
7. Common XID – the MicroTx coordinator for XA transactions will now try to minimize the number of branches by reusing existing branches if possible, instead of creating new branches.  This provides performance improvements when multiple participants use the same resource manager.  If all the participants are using the same resource manager, the transaction will end up being a single branch that can be committed with a one phase commit, eliminating the need for the prepare phase.
8. XA Transaction Promotion – this feature allows a transaction to start as a local RM transaction and only when another resource manager may become involved in the transaction does it get promoted to a full XA transaction.  This is currently only supported with Oracle Database.
9. Grafana Dashboards – the MicroTx coordinators now provide metrics that can be collected by Prometheus and visualized using predefined dashboards in Grafana.
10. Unlimited Transactions – the Free edition of MicroTx has a limitation of 4,800 transactions/hour.  This limit is removed in the Enterprise Edition, so production deployments are free to process as many transactions as needed.

With this release, MicroTx is now ready for your production deployments.  MicroTx EE is licensed as part of GoldenGate for Distributed Applications and Analytics. Get started for free using MicroTx Free and then upgrade to MicroTx EE when moving to production.

Source: oracle.com

Continue reading

Integrating Helidon and WebLogic Microservices with Oracle MicroTx

Introduction

More and more businesses are adopting microservices. This may be for green field developments where everything can start as a microservice. Or it may be building microservices that need to interact with or leverage existing, typically monolithic applications. Few companies can afford to build completely net new microservice based applications to replace their existing applications. The best alternative is to create new features using microservices and capitalize on the existing application until it can be replaced, in whole or piecemeal. 

In this post, I’ll cover a use case where an existing money management application already exists built using Oracle WebLogic Server. While this example will use JAX-RS and JPA, JDBC as well as EJB or JMS based applications can also be integrated by providing a JAX-RS interface to those applications.

Here is a diagram of the sample application that will be covered in this post:

Understanding the Sample

The basic scenario is an existing WebLogic Server JAX-RS JPA based web application that manages account balances and can have funds deposited to or withdrawn from that balance. A new application is being created using microservices that needs to integrate with this existing WebLogic application. These new microservices are written in Java using Helidon. They provide deposit and withdrawal services.

The issue now is how can one ensure that operations such as transferring funds, to or from, the existing application and the new microservices occur atomically? Fundamentally this is a dual write problem where the write to the source account and the destination account must both succeed or both fail. This is where distributed transactions come into the picture. Normally in WebLogic applications, the internal WebLogic Java Transaction Service is used. It provides XA distributed transaction support across multiple resource managers as well as across WebLogic applications deployed in other WebLogic servers. It can also support transactions spread across other application servers when using SOAP based web services with WS-AtomicTransaction and associated protocols. However, managing transactions that span other technologies, such as Helidon or Node.js or when using REST based services requires another solution.

This is where the Oracle Transaction Manager for Microservices (MicroTx) comes into the picture. MicroTx provides an external transaction coordinator for REST based services. Using MicroTx, the existing WebLogic application with some minor configuration change can be integrated with the new Helidon based microservices while ensuring transactional integrity across the participating systems. 

With MicroTx, a microservice can start a transaction and call other microservices that should be included in the transaction. This sample application shows one Helidon microservice that is acting as a sort of bank teller. The teller microservice allows a user to request that funds be transferred from one account to another account. However, those accounts may be held in different systems using different frameworks or languages. In this case, one account is provided by the WebLogic application, and the other is a new microservice running in Helidon.

For a JPA based application like the WebLogic sample application for MicroTx, no code changes are required, just some additional configuration to include the MicroTx client library and define a single property. 

This diagram shows how filters are used to propagate transaction context from one microservice to another.

Once these configuration changes are made, the application can participate in distributed transactions that are managed by MicroTx.

For the new Helidon teller microservice, which we call the initiator as it’s the one initiating the transaction, all that is required is to include the MicroTx client library and add the @Transactional annotation:

@Transactional(Transactional.TxType.REQUIRED)

on the method handling the transfer function. This annotation tells MicroTx that this method must be part of a transaction and begins a new transaction if one is not already present. In addition, if the method returns successfully, then the transaction is automatically committed by MicroTx. If the method generates an exception, the transaction is automatically rolled-back.

When the teller microservice makes a REST call to withdraw money from one of the participants, the MicroTx client library filters add headers to the outbound REST request to indicate to the participant that it should participate in the transaction. The incoming filters in the participant then enlist the participant in the transaction by calling the MicroTx coordinator and establish a transaction context in the participant.

Once the teller microservice has decided the transaction should be committed, it returns success which causes the MicroTx library to ask for the transaction to be committed by calling the transaction coordinator. The transaction coordination service then calls back to each of the enlisted participants to ask them to prepare. If that succeeds, it then asks all the participants to commit. If one or more of the participants cannot prepare, or the initiator decides to abort the transaction, the transaction will be rolled-back. Otherwise, the transaction will be committed. The initiator can abort the transaction by throwing an exception.

This overall flow is shown in this diagram:

In the transaction flow depicted above, MicroTx manages the details of distributed transaction processing so that the application developer does not have to. The interactions in green are completely handled by the MicroTx library. From a developer point of view, MicroTx makes this easy. Use an annotation within Helidon, and configuration within WebLogic Server, and MicroTX will manage the distributed transactions for you.

Note that this is a bit different than the way XA transactions are normally handled. In the typical XA transaction manager implementation, the transaction manager has its own connections to the resource manager. Which means the transaction manager needs its own credentials as well as the appropriate client library for the resource manager. To allow the MicroTx transaction manager to support any resource manager, it proxies its requests to the participant, which already has a connection to the resource manager. This makes the MicroTx transaction coordinator largely resource manager agnostic.

Source: oracle.com

Continue reading

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

Continue reading

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.

Source: oracle.com

Continue reading