6.1.3 Optimizations for a Non-XA Resource

Use the Logging Last Resource (LLR) or Last Resource Commit (LRC) optimization to enable one non-XA resource to participate in a global transaction.

Your microservice may contain several participant applications, where each application may be connected to a different resource manager. For example, a microservice contains a transaction initiator application which uses Oracle Database as the resource manager and a transaction participant application which uses MongoDB as the resource manager. MongoDB does not support the XA protocol. However, both MongoDB and Oracle Database need to participate in a global transaction. With MicroTx, you can use the XA transaction protocol for such a microservice when you enable LLR or LRC optimization.

About Logging Last Resource (LLR) Optimization

Use the LLR optimization to enable one non-XA resource to participate in a global transaction with the same ACID guarantee as XA.

XA resources can handle the XA requests sent by the transaction coordinator, such as prepare, commit, and rollback. Non-native or non-XA resources cannot handle such requests. The LLR and LRC optimizations enable a single non-XA resource to participate in an XA transaction. The transaction coordinator prepares all the other branches of the transaction, and then attempts to perform a local transaction commit to the LLR or LRC branch. Assuming that all the other branches are prepared without an issue, the outcome of the local commit determines the outcome of the transaction. If the local commit takes place successfully, the transaction is committed successfully, otherwise the transaction is rolled back.

Before performing a local commit, the transaction coordinator creates a commit record in the LLR branch. In case of any failure, the transaction coordinator tries to recover the list of transactions by calling xa_recover on the LLR branch. If the LLR branch had successfully committed its local transaction, the commitRecord returns the list of prepared participants. If the LLR branch failed to commit its local transaction, the recover() method returns an indication that no participants were recorded.

By default, the commit records are deleted after two hours. You can modify the time period for which the commit records are retained by specifying the time period in the oracle.tmm.LlrDeleteCommitRecordInterval property. For example, if you specify 600000 ms or 10 minutes, then only the commit records that were created during the last 10 minutes are retained and the previous records are deleted.

If the LLR branch succeeds in committing the local transaction that also includes the commit record for the transaction coordinator, then recover() returns the commit record.

About Last Resource Commit (LRC) Optimization

You can use the LRC optimization to enable one non-XA resource to participate in a global transaction without the same ACID guarantee as XA.

In LRC, the sequence of flow of the transaction is nearly identical to LLR. When the initiator calls commit on the transaction coordinator, the transaction coordinator prepares all the XA branches, and then calls commit() on the LRC branch. The only difference is that you can't recover the transaction details in case of any failure as the commit() method returns NULL as the value for commitRecord in LRC. In LLR, the commit() method returns a list of prepared participants in response. When commit() is called in LRC, the local transaction is committed and the outcome is returned to the transaction coordinator, but information about the prepared participants is not stored.

As information about the transaction log details is not stored, LRC optimization works with all supported resource managers. However, the possibility of heuristic outcomes increases as there is no way for the transaction coordinator to check if the local commit was completed successfully. Also, you can't use the recover() methods in LRC, so you can't recover the transaction in case of any failure.

Choose between LLR and LRC

Oracle strongly recommends that you use the LLR optimization for your non-XA resource as you can recover details in case of a failure. Use the LRC optimization only when your non-XA resource cannot store the commitRecord details or transaction log details.

Limitations

• MicroTx supports only one participant application with a non-XA resource to participate in XA transactions with LLR or LRC optimization. If your microservice has multiple non-XA resources, then MicroTx does not support the XA transaction protocol for this microservice. For example, the following error message is displayed if you try to use multiple LLR or LRC participants: Only one LLR or LRC participant is allowed to enlist.

If the initiator application participates in the transaction after starting the transaction, then you can use an LLR or LRC resource with this initiator application.