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.
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
![[iSeries]](../../iseries.gif)
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.
![[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.
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.