This topic describes some considerations and actions that you can take to configure transaction-related aspects of application servers for optimum availability.
Why and when to perform this task
To configure transaction-related aspects of application servers for optimum availability, complete the following steps:
Steps for this task
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.
Hardware disk mirroring or dual-ported disks can be used by specifiying the appropriate file system directory for the transaction logs using the WebSphere Administrative Console.
Note: The TRANLOG_ROOT variable was used in previous versions of WebSphere Application Server to override the default location of the transaction log, but is now deprecated. In a future version of WebSphere Application Server, transaction and compensation logs will move to a different default location and the variable TRANLOG_ROOT will be removed.
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 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.
On Application Server Network Deployment, the node agents automatically redirect such remote object references to the appropriate application servers on recovery. However, if the distributed transaction is between application servers that are not on Application Server Network Deployment, then you must handle the redirection of remote object references for transaction recovery to complete. For example, you must do this is 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 shut down. This prevents transaction recovery 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 Object Request Broker service custom properties). You may need to make similar configuration changes to other application servers involved in transactions, to be able to access those servers during recovery.