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 and not make use of network
mounted devices.
- 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 WebSphere 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.
![[AIX HP-UX Linux Solaris Windows]](../../dist.gif)
For example, the default directory for an application server
named
server1 is
/IBM/WebSphere/AppServer/profiles/profile_name/tranlog/server1
![[z/OS]](../../ngzos.gif)
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, 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, the remote object references saved in
the transaction log need 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 (not the 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 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 ORB service settings
that can be added to the administrative console). You may need to make
similar configuration changes to other application servers involved in transactions,
to be able to access those servers during recovery.