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 perform this task when you want to move the transaction logs
to a different storage device, or when you need to change the transaction
service settings. You must restart the application server to make
configuration changes take effect.
- 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.
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.If you do not enter a value for the Transaction
log directory, the application server assumes a default
location in the appropriate profile directory.
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 transactions 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 you
enable high availability. You must also ensure that each server in
the cluster has a unique log directory, so that multiple servers do
not attempt to access the same log file.
You can also specify
a size for the transaction logs, as described in the following step.
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 problem and a 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 also
specify a size for the transaction logs, as described in the following
step.
- 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 HP-UX Linux Solaris Windows]](../../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
For a z/OS system, you might want to reduce the size
of the transaction logs to ensure that they do not exceed the maximum
amount of data space storage is allocated for memory mappings (the
MAXMMAPAREA parameter).
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.
For more information about transaction log sizes,
see Managing transaction logging for optimum server availability.
Optional: Increase the storage
space that is used for memory mapping for transaction log files.
You can modify the MAXMMAPAREA parameter, which 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 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.
Optional: Disable MMAP functionality.
Set the com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles property.
Avoid trouble: With this option set, the behavior is the same
as it was before z/OS Version 1.9. You do not need to adjust MAXMMAPAREA.
gotcha
- From the administrative console, select .
- Click .
- Click New. Enter the information
for the com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles property.
Table 1. com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles
property
Name |
Value |
com.ibm.ws.recoverylog.spi.NoMemoryMappedFiles |
true |
- Click OK.
- Save your configuration and synchronize the changes.
- Optional: Review or change the value of transaction
timeout properties:
- Total transaction lifetime timeout
- Type 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.
- Maximum transaction timeout
- Type 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.
This value should 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 case, transactions that are affected
by this timeout never time out.
- Client inactivity timeout
- Type 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
trying again to send 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 property 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 also specifies how a transaction
is completed in the following situations:
- During recovery, the heuristic retry limit is exceeded.
- The transaction is imported from a Java EE Connector Architecture
(JCA) provider.
- 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.
- Review or change other configuration properties, to suit
your requirements. For more information about the properties
of the transaction service, see Transaction service settings.
- Click OK and save.
- Stop, then restart, the application server.
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. If you want 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.