Avoiding transaction timeouts in non-ASF mode
If your messaging system runs in non-Application Server Facilities (non-ASF) mode, you must configure the Total transaction lifetime timeout transaction service property and the NON.ASF.RECEIVE.TIMEOUT message listener service custom property correctly, to avoid unwanted transaction timeouts.
Before you begin
To carry out the steps in this task, your messaging system must be running in non-ASF mode. To change from ASF mode to non-ASF mode, add the NON.ASF.RECEIVE.TIMEOUT custom property to the message listener service as described in Configuring the message listener service.
About this task
For WebSphere® Application Server Version 7 and later, listener ports are stabilized. For more information, read the topic about stabilized features. Plan to migrate your WebSphere MQ message-driven bean deployment configurations from using listener ports to using activation specifications. However, do not begin this migration until you are sure the application does not have to work on application servers earlier than WebSphere Application Server Version 7. For example, if you have an application server cluster with some members at Version 6.1 and some at a later version, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to the later version.
If your messaging system is running in non-ASF mode, to avoid unwanted
transaction timeouts, you must allow a sufficient amount of time for processing to be completed
before the total transaction lifetime timeout is reached. Therefore, you must make sure that the
value that you specify for the NON.ASF.RECEIVE.TIMEOUT message listener service
custom property is smaller than the value that you specify for the Total transaction
lifetime timeout transaction service property, and also that the difference between the
values of the two properties is greater than the amount of time that the
onMessage()
method of the message-driven bean (MDB) takes to
process the message.
Procedure
- To configure the Total transaction lifetime timeout transaction service property, complete step 8 in Configuring transaction properties for an application server.
- To configure the NON.ASF.RECEIVE.TIMEOUT message listener service custom property, click .
- Click NON.ASF.RECEIVE.TIMEOUT.
The General Properties page is displayed.
- Modify the Value field.
The value of NON.ASF.RECEIVE.TIMEOUT must be specified in milliseconds. Make sure that the value you specify, when converted into seconds (by dividing by 1000), is less than the value that you specified for Total transaction lifetime timeout, and that the difference between the values of the two properties is greater than the maximum number of seconds that the onMessage() method of your MDB takes to process a message.
- Click OK.
- Stop and restart the application server.
Example
receive()
method as soon as the transaction is created. In the
following example, NON.ASF.RECEIVE.TIMEOUT is set to
110000 milliseconds (110 seconds), Total transaction lifetime
timeout is set to 120 seconds and the onMessage () method of the
MDB takes 15 seconds to process a message. The example supposes that a message does not appear at
the destination until the receive()
method has almost timed out:- The listener port starts and allocates a thread from the thread pool and creates a transaction on the thread.
- The thread calls the
receive()
method to listen for messages. - After 110 seconds a message appears at the destination.
- The thread removes the message from the destination and calls the
onMessage()
method of the MDB to begin processing the message. - Ten seconds later, the transaction timeout is reached. The application server marks the transaction for rollback.
- Five seconds later, the
onMessage()
method finishes processing the message and tries to commit the transaction. - The total amount of time that has elapsed since the transaction was started is 125 seconds (110 seconds waiting for a message, plus 15 seconds to process the message). As this time is longer than the transaction timeout, the application server prevents the transaction from being committed, and it is rolled back.