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 Solaris HP-UX Linux 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, 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.
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.