Configure transaction aspects of servers for optimum availability
This topic describes some considerations and actions that you can take to configure transaction-related aspects of appservers for optimum availability.
To configure transaction-related aspects of appservers 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 cycling 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 specifiying the appropriate file system directory for the transaction logs using the WebSphere Administrative Console.
- Specify the optimum location of the transaction log directory for appservers.By default, an appserver places transaction log files in a subdirectory of the installed WAS, where the subdirectory name is the same as the server name. For example, the default directory for an appserver named server on Windows is c:\WebSphere\AppServer\tranlog\server.
Note that The TRANLOG_ROOT variable was used in previous versions of WAS to override the default location of the transaction log, but is now deprecated. In a future version of WAS, 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 appserver by setting the Transaction Log Directory property for the server.
- Never allow more than one appserver 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 cycling the failed server or moved to an alternate server or machine and another server cycled to perform recovery, as described in the related tasks.
Never allow more than one appserver 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 appservers to always use the same listening port address at each startup.If you are running distributed transactions between multiple appservers, the remote object references saved in the transaction log need to be redirected to the originating server on recovery.
On Application Server Network Deployment, the node agents automatically redirect such remote object references to the appropriate appservers on recovery. However, if the distributed transaction is between appservers that are not on Application Server Network Deployment, then handle the redirection of remote object references for transaction recovery to complete. For example, do this is if an appserver 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 appserver 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, always configure appservers to always use the same listening port address at each startup (see ORB property com.ibm.CORBA.ListenerPort in Object Request Broker service settings that can be added to the administrative console). You may need to make similar configuration changes to other appservers involved in transactions, to be able to access those servers during recovery.
See Also
Moving a transaction log from one server to another
Restarting an appserver on a different host
Managing transaction logging for optimum server availability