4 Using Transaction Guard
Transaction Guard provides a generic infrastructure for applications to use for at-most-once execution during planned and unplanned outages and duplicate submissions. Applications use the logical transaction ID to determine the outcome of the last transaction open in a database session following an outage.
Without Transaction Guard, applications that attempt to replay operations following outages can cause logical corruption by committing duplicate transactions.
Transaction Guard provides these benefits:
-
Preserves the commit outcome
-
Ensures a known outcome for every transaction
-
Provides at-most-once transaction execution
This chapter contains the following topics:
Overview of Transaction Guard
The main purpose of Transaction guard is to provide at-most execution semantics in case of failures. The semantics assure that end-user transactions are executed on time and at-most-once.
For current applications, in case of communication failure to the server, determining the outcome of the last commit operation in a guaranteed and scalable manner becomes a challenge. In many cases, the end users are asked to follow certain steps to avoid resubmitting duplicate request. For example, some applications warn users not to click the Submit button twice because if it is not followed, then users may unintentionally purchase the same items twice and submit multiple payments for the same invoice.
Without Transaction Guard, if a transaction has been started and commit has been issued, the commit message that is sent back to the client is not durable. The client is left not knowing whether the transaction committed. The transaction cannot be validly resubmitted if the non-transactional state is incorrect or if it already committed. In the absence of guaranteed commit and completion information, re-submission can lead to transactions applied more than once and in a session with the incorrect state.
It's possible to use global XA transactions to limit the problem described above. However, there is overhead associated with the protocols required for XA processing. Further, some features like application continuity are not available with XA transactions.
WebLogic Server Transaction Management integrates with Transaction Guard internally to determine the state (commit outcome) of transactions during failures. The benefits of this integration is reducing heuristic exceptions in the case of global transactions with more than one resource, and reducing system exceptions in the case of one-phase transactions with only one resource. The implementation of this integration is internal to WebLogic Server and does not require changes to the application code.
If there is an exception during the completion of the transaction, WebLogic Server uses Transaction Guard to determine the transaction result. No changes are needed in the application code.
For more information about Transaction Guard, see Transactions in the Oracle Database guide.
Enabling Transaction Guard
Transaction Guard must be configured both in the data source and in the database service.
Enabling Transaction Guard for WebLogic Data Sources
weblogic.jdbc.commitOutcomeEnabled to true.
jdbcSR = create(dsname, 'JDBCSystemResource')
jdbcResource = jdbcSR.getJDBCResource()
driverParams = jdbcResource.getJDBCDriverParams()
driverProperties = driverParams.getProperties()
tgprop = driverProperties.createProperty('weblogic.jdbc.commitOutcomeEnabled')
tgprop.setValue('true')While trying to get the status of the transaction using Transaction Guard, it is possible for the operation to time out and the transaction will fail. The timeout for connections on a datasource with transaction type EmulateTwoPhaseCommit, OnePhaseCommit, or LoggingLastResource uses the XA completion-timeout value. The timeout for connections on a datasource with transaction type None (e.g., outside a transaction) is 10 seconds.
To override the default value, use the weblogic.jdbc.commitOutcomeRetrySeconds connection property. For example, add the following to the WLST script above.
tgseconds = driverProperties.createProperty(
'weblogic.jdbc. commitOutcomeRetrySeconds’)
tgseconds.setValue('60')Note:
This feature is supported in a global transaction that has both XA and non-XA resources or has multiple EmulateTwoPhaseCommit resources. Global transactions with more than one participating resource can still experience heuristic outcomes. The use of the Transaction Guard feature on the datasource(s) does not guard against the inherent potential for non-atomic/heuristic outcome for this type of global transaction.Enabling Transaction Guard for Database Service
the-commit_outcome parameter set to TRUE and optionally set the retention timeout.
For example:
srvctl modify service -d mydb -s myservice -e TRANSACTION -commit_outcome TRUE -retention 604800 -rlbgoal SERVICE_TIME -clbgoal SHORT
Data Source Statistics for Transaction Guard
Learn about Data source statistics available on the weblogic.management.runtime.JDBCDataSourceRuntimeMBean for transaction guard.
The following related statistics are available on the weblogic.management.runtime.JDBCDataSourceRuntimeMBean.
public long getResolvedAsCommittedTotalCount();
The cumulative total number of commit outcomes successfully resolved as committed in this data source since the data source was deployed.
public long getResolvedAsNotCommittedTotalCount();
The cumulative total number of commit outcomes successfully resolved as committed in this data source since the data source was deployed.
public long getUnresolvedTotalCount();
The cumulative total number of commit outcomes unsuccessfully resolved in this data source since the data source was deployed.
public long getCommitOutcomeRetryTotalCount();
The cumulative total number of commit outcome query retries conducted before resolving the outcome or exceeding the retry seconds in this data source since the data source was deployed.