client inactivity timeout

WebSphere Application Server

http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-dist&topic=Transaction_service
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

http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-dist&topic=tjta_settlog
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.

http://www-01.ibm.com/support/docview.wss?uid=swg1PK07143
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
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s