XA two phase commit protocol

The XA two phase commit protocol works as follows:

The XA transaction coordinator (WebSphere) calls all the Resource Managers (RMs) in the transaction and tells them to Prepare to commit. Typically at this point they write the updates and create logs to enable backout, while locking the newly committed data.

Any RM can abort the transaction, in which case the TM tells everyone to roll back.

Once all participants agree to commit, the TM then tells all the RMs to commit (phase 2). At this point all the logs are cleaned up and locks are removed.

If the server crashes in the middle of this process there may be uncomitted transactions in various logs (WebSphere and the resource managers – databases, queueing systems etc). If you delete the tranlog you may leave data in an inconsistent state, and you may leave a database with locks held against rows that were being modified by the transaction that was inflight. This can be dangerous. Normally bringing up all the RMs and then restarting WAS will cause a normal recovery to occur. There are some cases where it is not automatically clear what needs to be done, and an admin may need to explicity go into the database and force a transaction to go away. You may see this in-doubt situation called “heuristic damage”.


client inactivity timeout

WebSphere Application Server

Specifies the maximum duration, in seconds, between transactional requests from a remote client. Any period of client inactivity that exceeds this timeout results in the transaction being rolled back in this application server.

If you set this value to 0, there is no timeout limit.

Data type | Integer
Units     | Seconds
Default   | 60
Range     | 0 to 2147483647

The number of seconds after which a client is considered inactive and the transaction service ends any transactions associated with that client. A value of 0 (zero) indicates that there is no timeout limit.

Given the following topology:

   Server 1             Server 2
    EJB 1                EJB 2

If EJB 1 makes a call to EJB 2, and EJB 2 returns correctly, but the transaction on EJB 1 lasts long enough to cause a client inactivity timeout on Server 2, Server 1 will not know until its transaction is finished running. If the transaction lasts a long time, the EJB on Server 1 could potentially run for 30 minutes or more and not realize it will have to perform a rollback, because of the client inactivity timeout.

The operation is working as designed, but Server 1 should have some way of knowing that it will have to perform a rollback before it spends 30 minutes doing work that will just get rolled back anyway. Currently it cannot know.

Local fix

There are two options:

1. Set the client inactivity timeout to a value long enough to avoid causing the rollback in the first place.

2. Use an intermediary EJB on Server 1 that uses TX_REQUIRES_NEW or TX_NOT_SUPPORTED before it then forwards the request to Server 2. In this way, the transaction on Server 1 will be suspended before the client call to Server 2. When the transaction on Server 1 resumes, it will not care about keeping Server 2 in the loop and the timeout won’t occur because Server2 was never made a part of Server 1’s transaction.

server1 client inactivity timeout is set to 60 secs
server1 Total transaction lifetime timeout 120 secs

server2 client inactivity timeout is set to 90 secs
server2 Total transaction lifetime timeout 120 secs

ejb1 deployed on server1
ejb2 deployed on server2

if ejb1 calls ejb2 (method ejb2_m1) and after the call ejb1 keep doing something else for more then 90 secs (server2 client inactivity timeout) and doesnt call anyother methods (including ejb2_m1) on ejb2 then ejb2 will detect client inacticity and rollback the transaction after 90 secs of completion of last call.

so what the point of ‘client inactivity timeout’ and why it needed when ‘Total transaction lifetime timeout’ is there why not make it default 0.

Total transaction lifetime timeout
The default maximum time, in seconds, allowed for a transaction that is started on this server before the transaction service initiates timeout completion. Any transaction that does not begin completion processing before this timeout occurs is rolled back.

Maximum transaction timeout
Specifies, in seconds, the upper limit of the transaction timeout for transactions that run in this server. This value should be greater than or equal to the value specified for the total transaction timeout.

This timeout constrains the upper limit of all other transaction timeouts. The following table shows how the different timeout settings apply to transactions running in the server.

Transaction timeout settings.
Timeout setting                    | Transactions affected
Maximum transaction timeout        | All transactions running in this server that are not affected by the total transaction lifetime timeout or an application component timeout. These transactions include transactions imported from outside this server, such as those imported from a client.
Total transaction lifetime timeout | All transactions that originated in this server that are not affected by an application component timeout, in other words, the associated application component does not set its own timeout.
Application component timeout      | Transactions that are specific to an application component. If the component is a container-managed bean, set this timeout in the deployment descriptor for the component. If the component is a bean-managed bean, set this timeout programmatically using the UserTransaction.setTransactionTimeout method.

If you set a timeout to 0, that timeout does not apply, and is effectively disabled. If you set all timeouts to 0, transactions never time out.

For example, consider the following timeout values:

Maximum transaction timeout        360
Total transaction lifetime timeout 240
Application component timeout       60

In this example, transactions that are specific to the application component time out after 60 seconds. Other local transactions time out after 240 seconds, and any transactions that are imported from outside this server time out after 360 seconds. If you then change the application component timeout to 500, application component transactions time out after 360 seconds, the value of the maximum transaction timeout. If you set the maximum transaction timeout to 0, application component transactions time out after 500 seconds. If you remove the application component timeout, application component transactions time out after 240 seconds.
To determine the occurrence of a timeout quickly, and to prevent further resource locking, the application server prevents further transactional work on the transactional path where the timeout condition has taken place. This applies equally to attempting to perform work under the current transaction context and to attempting to perform work under a different transactional context.

Data type | Integer
Units     | Seconds
Default   | 300
Range     | 0 to 2 147 483 647
Range     | 0 to 2 147 040

Websphere class loaders

  1. Bootstrap
    • jre/lib
    • jre/lib/ext
    • CLASSPATH environment variable
  2. Extension
    • ws.ext.dirs system property to determine the path that is used to load classes.
  3. Application module classloaders
    • shared libraries
  4. Web module classloaders
    • WEB-INF/classes
    • WEB-INF/lib

Updating ejb deployment descriptor in installed applications with the wsadmin tool

open wsadmin shell

ksh ./wsadmin.sh -lang jython -conntype SOAP -host yourhost.com -port 8879 -user userid -password password

print AdminApp.update('MyAppName', 'file', '[-operation update -contents /home/users/sg/1.xml -contenturi MyEJB.jar/META-INF/ejb-jar.xml]')


  • ‘MyAppName’ is display name of my application, deployed with .ear file
  • /home/users/sg/1.xml ejb deployment descriptor that I want to update in my application
  • MyEJB.jar/META-INF/ejb-jar.xml MyEJB.jar is the ejb deployed with in enterprise application (EAP), I want to update deployment descriptor of this ejb.
  • NOTE that -contenturi is
    if you put , instead of / you will get
    com.ibm.websphere.management.exception.AdminException: ERROR: File does not exist for update operation

    P.S always look in dmgr logs for errors in deployment.