You can view or change settings for the transaction service.
For example, you can change the location or default file size of the
transaction log files, change transaction timeout properties, or change
heuristic-related properties.
About this task
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.
You
might undertake this task when you want to move the transaction logs
to a different storage device, or when you have to change the transaction
service settings. You must restart the application server to make
configuration changes take effect.
For transitioning users: The approach taken to changing the size
of transaction log files and enabling MMAP functions has changed from
previous versions.
trns
Procedure
- In the administrative console, click . The properties of the application
server, server_name, are displayed in the content
pane.
- Click . The Transaction Service settings
page is displayed.
- Ensure that the Configuration tab is displayed.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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. You can check the current runtime value of Transaction
log directory by clicking the Runtime tab.When
you use WebSphere® Application
Server without high availability support, you 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.
Note: If you 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.
You
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. Use 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 you can specify is 64K. If you specify a value that
is less than 64K, or you 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
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
In a non-production environment, you 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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
For
more information about transaction log sizes, see Managing transaction logging for optimum server availability.
Optional: Set the com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles
property to use memory mapping for the transaction log files on z/OS®.
Avoid trouble: With this option set, you will need to set the
size of the transaction log files with care. You can 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 you can reduce the size of the transaction logs, or increase
the storage space that is 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.
gotcha
The
following example shows how to calculate the value for the OMVS parameter,
if you 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 that are 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 .
- Click .
- 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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
If you are running your messaging system
in non-ASF mode, you must 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.
This property applies only to transactions that are 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 that contains a one-phase resource. This setting configures
last participant support (LPS) for the server. If you do not select
this option, you must 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 your changes
to the master configuration.
- Stop, then restart, the application server.
What to do next
If you 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
you 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.