Configure transaction properties for an application server
Overview
We can view or change settings for the transaction service. For example, we can change the location or default file size of the transaction log files, change transaction timeout properties, or change heuristic-related properties.
The transaction service is a server runtime component that can coordinate updates to multiple resource managers to ensure atomic updates of data. Transactions are started and ended by applications or the container in which the applications are deployed.
We might undertake this task when we want to move the transaction logs to a different storage device, or when we have to change the transaction service settings. We must restart the application server to make configuration changes take effect.
For transitioning users: In v8.5.5, the approach taken to change the size of transaction log files and enable MMAP functions changed from previous versions.trns
Configure transaction properties
- In the administrative console, click...
- Servers | Server Types | WebSphere application servers | server | [Container Settings] | Container Services | Transaction Service
The Transaction Service settings page is displayed.
- Ensure that the Configuration tab is displayed.
- Optional: To change the directory in which transaction logs are written, type the full path name of the directory in the Transaction log directory field. We can check the current runtime value of Transaction log directory by clicking the Runtime tab.
When we use WebSphere Application Server without high availability support, we do not need to set the recovery log configuration for persistent services such as the transaction service. The application server assumes a default location in the appropriate profile directory. When high availability support is enabled, this default might not be visible from all servers in the cluster (for example, if the servers are in different profiles or physical nodes.) Because of this behavior, configure the recovery log location for each server in the cluster before enabling high availability. Ensure that each server in a cluster has a unique transaction log directory, so that multiple servers do not attempt to access the same log file. Also, ensure that each server in a cluster can access the transaction log directories of the other servers in the cluster.
In a high availability (HA) environment, both the transaction log and the compensation log directory for each server in a cluster must be unique.
If we change the transaction log directory, apply the change and restart the application server as soon as possible, to minimize the risk of problems occurring before the application server is restarted. For example, if there is a problem and the server fails with in-flight transactions, when the server restarts, it uses the new log directory and cannot automatically resolve in-flight transactions that were recorded in the old log directory.
We can specify a size for the transaction logs, as described in step 5.
- Optional: To change the size of transaction log files, modify the Transaction log
directory field to include a file size setting. Using one of the following formats, where
directory_name is the name of the transaction log directory and file_size is the disk space allocation for the transaction log files, specified
in kilobytes (nK) or megabytes (nM). The minimum transaction
log file size that we can specify is 64K. If we specify a value that is less than 64K, or we do not specify a value for the file size, the default value of 1M is used.
;file_size <!-- This format keeps the default directory -->
directory_name;file_size
dir://directory_name/directory_name;file_size
/directory_name/directory_name;file_size
(Dist) For example, for a Windows system, the following entry specifies that transaction log files are created in the directory c:\tranlogs with a size of 2 megabytes.
c:\tranlogs;2M
In a non-production environment, we can turn transaction logging off by entering ;0 in the Transaction log directory field (do not enter a directory name). Do not turn transaction logging off in a production environment because this prevents recovery after a system failure, and therefore data integrity cannot be guaranteed.
For more information about transaction log sizes, see Manage transaction logging for optimum server availability.
- Optional: (ZOS) Set the com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles property to use memory mapping for the transaction log files on z/OS .
With this option set, we will need to set the size of the transaction log files with care. Use the MAXMMAPAREA parameter to set the size of the transaction log files to ensure that they do not exceed the maximum amount of data space storage that is allocated for memory mappings. For example, by modifying the MAXMMAPAREA parameter we can reduce the size of the transaction logs, or increase the storage space used for memory mapping for transaction log files. MAXMMAPAREA specifies the maximum amount of data space storage, in pages, that can be allocated for memory mappings of the transaction log files. There are two transaction log files, which are named log1 and log2, and each file is allocated 1 MB. Therefore, each server needs 512 pages by default. The following example shows how to calculate the value for the OMVS parameter, if we use the default size for log files:
MAXMMAPAREA = 512 x number_of_servers + (resources needed outside the application server)
where number_of_servers is the number of controllers running simultaneously, including application servers and the deployment manager, but not the node agent. The following steps will set the com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles property in order to use memory mapped files for transaction logging.- From the administrative console, select Servers > Server Types > WebSphere application servers > server.
- Click [Server Infrastructure] Java and Process Management > Process Definition > Java Virtual Machine > Control > [Additional Properties] Custom Properties.
- Click New.
- Enter the information for the com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles property.
Name Value com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles false
- Optional: Review or change the value of transaction timeout properties:
- Total transaction lifetime timeout
- The number of seconds to allow for a transaction that is started on this server, before the transaction service initiates timeout completion. If a transaction does not begin completion processing before this timeout occurs, it is rolled back. A value of 0 (zero) indicates that this timeout does not apply, and therefore the maximum transaction timeout is used instead. Application components can override the total transaction lifetime timeout for their transactions by setting their own timeout value.
- If we are running our messaging system in non-ASF mode, make sure that this property is correctly configured with the NON.ASF.RECEIVE.TIMEOUT message listener service custom property so that unwanted transaction timeouts are avoided. See the related links for more details.
- Maximum transaction timeout
- The number of seconds a transaction that is propagated into this application server can remain
inactive before it is ended by the transaction service. This value also applies to transactions that are started in this server, if their associated applications do not set a transaction timeout and the total transaction lifetime timeout is set to 0 (zero).
This value must be equal to, or greater than, the total transaction lifetime timeout. A value of 0 (zero) indicates that this timeout does not apply. In this situation, transactions that are affected by this timeout never time out.
- Client inactivity timeout
- The number of seconds after which a client is considered inactive and the transaction service ends any transactions associated with that client. A value of 0 (zero) indicates that there is no timeout limit.
- Optional: Review or change heuristic-related properties:
- Heuristic retry limit
- The number of times that the application server retries a completion signal, such as commit or rollback. Retries occur after a transient exception from a resource manager or remote partner, or if the configured asynchronous response timeout expires before all Web Services Atomic Transaction (WS-AT) partners have responded.
- Heuristic retry wait
- The number of seconds that the application server waits before retrying a completion signal, such as commit or rollback, after a transient exception from a resource manager or remote partner.
- Enable logging for heuristic reporting
- Select this option to enable the application server to log "about to commit one-phase resource" events from transactions that involve a one-phase commit resource and two-phase commit resources.
- Heuristic completion direction
- Select the direction used to complete a transaction that has a heuristic outcome; either the application server commits or rolls back the transaction, or depends on manual completion by the administrator.
The heuristic completion direction property specifies how a transaction is completed in the following situations:
- The transaction manager reports a heuristic outcome for a last participant support (LPS) resource.
- The heuristic retry limit is exceeded during the recovery of a subordinate server in a distributed transaction.
- The transaction is imported from a Java EE Connector Architecture (JCA) provider.
Applies to transactions in the situations just described.
- Accept heuristic hazard
- Select this option to specify that all applications on this server accept the possibility of a heuristic hazard occurring in a two-phase transaction containing a one-phase resource. This setting configures last participant support (LPS) for the server. If not selected, configure applications individually to accept the heuristic hazard.
- Optional: To change the default WS-Transaction specification level to use for outbound requests that include a web Services Atomic Transaction (WS-AT) or Web Services Business Activity (WS-BA) coordination context, select the specification level from the Default WS-Transaction specification level list.
- Review or change other configuration properties, to suit your requirements. For more information about the properties of the transaction service, see the topic about Transaction service settings.
- Click OK, then save the changes to the master configuration.
- Stop, then restart, the application server.
What to do next
If we change the transaction log directory configuration property to an incorrect directory name, the application server restarts, but cannot open the transaction logs. Change the configuration property to a valid directory name, then restart the application server.If we are running the application server as non-root, modify the permissions on the new transaction log location. To use peer recovery of transactions on a shared device with non-root users, make sure that your non-root users and groups have matching identification numbers across machines.
Subtopics
- Transaction service settings
- Transactions needing manual completion
- Transactions retrying resources
- Transactions with heuristic outcome
- Transactions imported and prepared
- Transaction resources
- Transaction service custom properties
Related: