Transaction service custom properties
WebSphere Application Server allows you to configure a number of custom properties for transaction services.
This topic references one or more of the application server log files. As a recommended alternative, we can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. We can also use HPEL in conjunction with the native z/OS logging facilities. If we are using HPEL, we can access all of the log and trace information using the LogViewer command-line tool from the server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.
Transaction service custom properties can be specified in the console. To use any of these custom properties click on Servers > Server Types > WebSphere application servers > server_name > [Container Settings] Container Services > Transaction Service > [Additional Properties] Custom Properties.
(zos) Avoid trouble: In z/OS ensure that all relevant log streams are set to AUTODELETE(NO).gotcha
We can define the following transaction service custom properties:
- DELAY_CANCELLING_ALARMS
- (zos) DISABLE_DEFERRED_CTX_REGISTRATION
- (zos) DISABLE_OUTBOUND_CASCADED_SUPPORT
- DISABLE_RECOVERY_AUDIT_LOGGING
- (zos) DISABLE_TRANSACTION_TIMEOUT_GRACE_PERIOD
- (zos) DISABLE_WSTX_RMFAIL_LOGGING
-
- ENABLE_XARESOURCE_TIMEOUT
- REMOVE_PARTNER_LOG_ENTRY
- (zos) RLS_LOGSTREAM_COMPRESS_INTERVAL
- (zos)(V8502) ZOS_RECOVER_BEFORE_COMMIT
DELAY_CANCELLING_ALARMS
If the before completion stage of a transaction process is likely to include processes that could either take a long time to complete or could fail, then you might want the transaction to time out.
By default, transaction timeout alarms are cancelled prior to the before completion phase of the transaction begins. The DELAY_CANCELLING_ALARMS custom property allows the before completion phase of the transaction to be encompassed within the transaction timeout period. To do this, set the custom property on the application server.
| Information | Value |
|---|---|
| Data type | Boolean |
| Acceptable values | TRUE, FALSE |
| Default | FALSE |
(zos) DISABLE_DEFERRED_CTX_REGISTRATION
By default, the registration of a WebSphere global transaction with the z/OS native transaction context is deferred until enlistment of resources with the global transaction occurs. This deferred registration is an enhancement designed to improve performance in scenarios when RRS resources are NOT involved in the current transaction (for example, when only XA resources are enlisted) - it avoids the extra processing related to registration with the native context when it is not subsequently required. If RRS resources are enlisted with the transaction, deferred registration still occurs, but does not provide any performance enhancement.
The DISABLE_DEFERRED_CTX_REGISTRATION custom property disables the deferring of registration of a WebSphere global transaction with the z/OS native transaction context. When deferred registration is disabled, the registration with the native transaction context automatically occurs during the creation of the WebSphere global transaction.
There are circumstances when it is not desirable to defer native context registration for RRS resources. In the following cases, set DISABLE_DEFERRED_CTX_REGISTRATION=true :
- An application activates cursor holdability, which under certain circumstances allows a result set to be kept open across transaction boundaries.
| Information | Value |
|---|---|
| Data type | Boolean |
| Acceptable values | TRUE, FALSE |
| Default | FALSE |
(zos) DISABLE_OUTBOUND_CASCADED_SUPPORT
Whether or not the transaction manager is to disable the support that allows initiating cascaded transactions and be able to let other WebSphere Application Servers on z/OS, who also support RRS cascaded transaction processing, be part of a cascaded family.
Set to true if we do not want outbound cascaded support. Setting this value to true will prompt the server to default to standard JTS transaction propagation.
| Information | Value |
|---|---|
| Data type | Boolean |
| Acceptable values | TRUE, FALSE |
| Default | FALSE |
DISABLE_RECOVERY_AUDIT_LOGGING
We can control whether information messages are displayed on the console and written to the SystemOut.log file upon transaction service recovery. To do this, set the DISABLE_RECOVERY_AUDIT_LOGGING custom property for the transaction service for the server.
On distributed platforms the default is for information messages to appear both on the console and in the SystemOut.log file during the recovery of transaction services. If we do not want these messages to be displayed we can use the DISABLE_RECOVERY_AUDIT_LOGGING custom property.
(zos) On z/OS information messages do not appear by default, either on the console or in the SystemOut.log file during the recovery of transaction services. These messages displayed we can use the DISABLE_RECOVERY_AUDIT_LOGGING custom property.
(zos) Note: On z/OS, if you choose to turn on transaction recovery audit messages, other audit messages (such as those relating to servant recovery and XA resource recovery) are also displayed in the console and the SystemOut.log file.
| Information | Value |
|---|---|
| Data type | Boolean |
| Acceptable values | TRUE, FALSE |
| Default |
FALSE (zos) TRUE |
(zos) DISABLE_TRANSACTION_TIMEOUT_GRACE_PERIOD
Whether there is a delay between a transaction timeout and the abnormal ending of the servant region that was running the transaction.
If we set this value to false, a global transaction that times out is marked rollback-only. The transaction server gives the associated application an additional period of time, approximately four minutes, to complete. If the application completes in this time, the transaction is rolled back. If the application does not complete in this time, the application and associated servant region are ended abnormally, with an ABENDEC3 or ABENDSEC3 error.
Set to true to remove the delay, and abnormally end the application and servant region immediately.
| Information | Value |
|---|---|
| Data type | Boolean |
| Acceptable values | TRUE, FALSE |
| Default | FALSE |
(zos) DISABLE_WSTX_RMFAIL_LOGGING
Whether an RMFAIL message is sent to the error log file when a WS-AT participant fails to send a response within the asynchronous response timeout period, causing an XAER_RMFAIL transaction exception to occur.
If we set this value to false, an RMFAIL message is sent to the error log file when a WS-AT participant fails to send a response within the asynchronous response timeout period.
Set to true if we do not want an RMFAIL message sent to the error log file when a WS-AT participant fails to send a response within the asynchronous response timeout period.
| Information | Value |
|---|---|
| Data type | Boolean |
| Acceptable values | TRUE, FALSE |
| Default | FALSE |
ENABLE_XARESOURCE_TIMEOUT
When true, the transaction service will provide a timeout value to XA resources when they are enlisted in global transactions. The timeout provided will be the remaining number of seconds before the transaction is set to timeout.
| Information | Value |
|---|---|
| Data type | Boolean |
| Acceptable values | TRUE, FALSE |
| Default | FALSE |
REMOVE_PARTNER_LOG_ENTRY
We can remove entries from the transaction partner log file. To do this, set the REMOVE_PARTNER_LOG_ENTRY custom property for the transaction service on the server that owns the partner log.
As part of the transaction recovery process, the partner log is checked to establish which resources are needed. To remove certain entries from the partner log, such as a resource that no longer exists, set this custom property on the application server that owns the transaction partner log containing the entries to remove.
The REMOVE_PARTNER_LOG_ENTRY custom property is effective only when both of the following situations apply.
- The application server is started in recovery mode.
- The application server has no transactions that currently require recovery. We can establish this by checking the SystemOut.log file.
| Information | Value |
|---|---|
| Data type | Integer |
| Acceptable values | (one or more comma-delimited integer recovery ID) |
| Default | (null) |
(zos) RLS_LOGSTREAM_COMPRESS_INTERVAL
Specifies, in seconds, the interval at which the recovery log service attempts to compress any log streams application components are using. The Transaction Service (XA partner log) and the Compensation Service components can be configured to use the recovery log service.
The log stream is checked for compression once per interval. This operation can cause unnecessary CPU usage if the log stream is not being used.
- If we do not use a log stream for the compensation service, set this property to a value that is higher than the default value.
- If the recovery log service uses log streams, do not set this property to too high a value. If the recovery log service log streams
become full before the compression interval expires, transactions might start to fail until the log streams are compressed.
- If none of the components are configured to use a log stream, you set this property to 0 (zero) to disable this function.
| Information | Value |
|---|---|
| Data type | Integer |
| Acceptable values | 0 - 2,147,483,647 (0 disables the function) |
| Default | 30 seconds |
(V8502) ZOS_RECOVER_BEFORE_COMMIT
Specify this property prevents a deadlock from occurring after an xa_recover call is issued against an MQ Server resource at recovery time. The MQ Server uses JCA 1.5 transaction in-flow interfaces as part of its normal operation. These interfaces enable MQ Server Bus member to coordinate WMQ and Service Integration Bus resources using WebSphere Application Server transactions. During the commit of any transaction at recovery time, xa_recover is called to ensure some older DB2 drivers do no return XAER_NOTA even if the transaction exists when the xa_commit or xa_rollback call is issued.
This deadlock occurs because the MQ Server resource issues calls back to the controller and attempts to lock all known transactions so that the MQ Server resource can generate a list of transactions that need to respond to the xa_recover call. However, because the IN-COMMIT transaction being committed is already locked, the xa_recover call waits indefinitely to lock the IN-COMMIT transaction because that transaction will not be unlocked until the transaction commits.
Set this property to FALSE ensures that during the processing of transactions at recovery time, the xa_recover call is not issued before an xa_commit or xa_rollback call.
Avoid trouble: All currently supported DB2 drivers have an auto-recover feature which makes it unnecessary to issue an xa_recover calls prior to issuing an xa_commit or xa_rollback call. If, after reading the documentation for the DB2 driver, you are not sure whether the DB2 driver includes the auto-recover feature, contact IBM DB2 support for final clarification on whether setting this property is safe to use for servers hosting applications that access DB2.gotcha
| Information | Value |
|---|---|
| Data type | Boolean |
| Acceptable values | TRUE, FALSE |
| Default | TRUE |
Related tasks