You can configure transaction-related aspects of application
servers to optimize the availability of those servers. This helps
your transactions to complete or recover more quickly. After changing
transaction-related properties of an application server, you must
restart the server.
- Store the transaction log files on a fast disk in a highly-available
file system, such as a RAID device. The transaction log
might have 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, these log files can be used when restarting
a failed server, or they can be moved to another machine and another
server can be started to undertake recovery.
You can configure
hardware disk mirroring or dual-ported disks by using the administrative
console to specify the appropriate file system directory for the
transaction logs.
- 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
For example, the default directory for an application
server named
server1 is
/QIBM/UserData/WebSphere/AppServer/was_version/ND/profiles/profile_name/tranlog/server1
where
was_version indicates
the version number for this installation of IBM
® WebSphere Application Server. For example
V6 for
WebSphere Application Server Version 6.
For example, the default directory for an application
server named
server1 is
/IBM/WebSphere/was_version/AppServer/profiles/profile_name/tranlog/server1
where
was_version indicates
the version, release and modification number for this installation
of IBM
WebSphere Application Server. For example
V6R0M2 for
WebSphere Application Server Version 6.0.2.
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,
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 cannot 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 might have 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, these log files can be used when restarting a
failed server, or they can be moved to another machine and another
server can be started to undertake 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, the remote object references saved in the transaction log
have to be redirected to the originating server on recovery.
On WebSphere Application Server, Network Deployment, the node agents
automatically redirect these remote object references to the appropriate
application servers on recovery. However, if the distributed transaction
is between application servers that are not on WebSphere Application Server, Network Deployment, 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, Network Deployment edition)
and runs distributed transactions with non-WebSphere EJB or Corba
servers.
In particular, the default restart action of an application
server not on Application Server WebSphere Application Server, Network Deployment 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 should always configure application servers to always use
the same listening port address at each startup (see the ORB property
com.ibm.CORBA.ListenerPort in the topic about Object Request Broker
custom properties). You might have to make similar configuration changes
to other application servers involved in transactions, to be able
to access those servers during recovery.