This topic describes some considerations and actions that
you can take to configure transaction-related aspects of application
servers, to optimize the availability of those servers.
About this task
This helps your transactions to complete or recover more
quickly. After changing transaction-related properties of an application
server, you must restart the server.
To configure transaction-related
aspects of application servers for optimum availability, complete
the following steps:
- Store the transaction log files on a fast disk in a highly-available
file system, such as a RAID device. The transaction log
may need to be accessed by every global transaction and be used for
transaction recovery after a crash. Therefore, the disk the log files
are being written to should be on a highly-available file system,
such as a RAID device.
The performance of the disk also directly
affects the transaction performance. In general, a global transaction
makes two disk writes, one after the prepare phase when the outcome
of the transaction is known (this information is forced to disk) and
a further disk write at transaction completion. Therefore, the transaction
logs should be placed on the fastest disks available.
In
order for automatic failover of transaction log recovery to work in
a WebSphere® Application
Server cluster topology, network mounted devices must be used for
the transaction logs, on a fast disk in a highly-available file system,
such as a RAID device, that each cluster member can access.
- Mirror the transaction log files by using hardware disk
mirroring or dual-ported disks. If log files have been
mirrored or can be recovered, they can be used when restarting a failed
server or moved to an another machine and another server started there
to perform recovery.
Hardware disk mirroring or dual-ported disks
can be used by specifying the appropriate file system directory for
the transaction logs using the administrative console.
- Specify the optimum location of the transaction log directory
for application servers.
By default, an application
server places transaction log files in a subdirectory of the installed WebSphere Application Server,
where the subdirectory name is the same as the server name.
For example, the default directory for an application
server named
server1 is
/IBM/WebSphere/AppServer/profiles/profile_name/tranlog/server1
You can define a specific location for the transaction
log directory for an application server by setting the Transaction
Log Directory property for the server. If the directory for the
transaction logs has not been created at application server start
up, the directory structure is created for you.
Note: If you change
the transaction log directory, you should 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 a problem causes the server to fail (with in-flight transactions),
the server next starts with the new log directory and is unable to
automatically resolve in-flight transactions that were recorded in
the old log directory.
- Never allow more than one application server to concurrently
use the same set of log files. Because the transaction
logs record the state of global transactions within a server, if the
logs become lost or corrupt, then transactions that are in the prepared
state before failure can leave resources in an in-doubt state and
prevent further updates or access to the resources by other users
or servers. These transactions may need to be manually resolved by
either committing or rolling back the transactions at the affected
resource managers. The failed server can then be cold-started, which
creates new empty transaction logs.
If log files have been mirrored
or can be recovered, they can be used when restarting the failed server
or moved to an alternate server or machine and another server restarted
to perform recovery, as described in the related tasks.
Never
allow more than one application server to concurrently use the same
set of log files, because each server will destroy the information
recorded by the other, resulting in corrupt log files that are unusable
for future recovery purposes.
- Configure application servers to always use the same listening
port address at each startup.
If you are running distributed
transactions between multiple application servers, for example non-WebSphere
EJB or Corba servers, the remote object references saved in the transaction
log need to be redirected to the originating server on recovery.
You
must handle the redirection of remote object references so that transaction
recovery can complete. For example, you must do this if an application
server is deployed on WebSphere Application
Server and runs distributed transactions with non-WebSphere EJB or
Corba servers.
In particular, the default restart action of
an application server is to use a different listening port address
to the port when the server shuts down. This prevents transaction
recovery from completing. To overcome this, you must configure application
servers to always use the same listening port address at each startup
(see the ORB property com.ibm.CORBA.ListenerPort in ORB service
settings that can be added to the administrative console).
You might need to make similar configuration changes to other application
servers involved in transactions, so that you can access those servers
during recovery.