WAS v8.5 > Administer applications and their environment > Welcome to administering Transactions > Administer the transaction service > Manage transaction logging for optimum server availability

Configure transaction aspects of servers for optimum availability

We 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. To configure transaction-related aspects of application servers for optimum availability...

1. 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.

2. Mirror the transaction log files 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.

   We can configure hardware disk mirroring or dual-ported disks using the dmgr console to specify the appropriate file system directory for the transaction logs.

3. 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 WAS, 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

   We 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.

   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.

4. 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.

5. Configure application servers to always use the same listening port address at each startup. If you are running distributed transactions between multiple application servers, for example non-WebSphere EJB or Corba servers, the remote object references saved in the transaction log have to be redirected to the originating server on recovery.

   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 WAS and runs distributed transactions with non-WebSphere EJB or Corba servers.

   In particular, the default restart action of an application server 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, 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, so that we can access those servers during recovery.

Related

Configure transaction properties for an application server
Moving a transaction log from one server to another
Restart an application server on a different host

Reference:

Object Request Broker custom properties

+

Search Tips   |   Advanced Search