Differences in transaction timeout handling between WebSphere Application Server v5.1 and 4.0 or 5.0.
 Technote (troubleshooting)
 
Problem(Abstract)
In WebSphere® Application Server version 5.1, once the transaction timeout message is thrown and a transaction rollback is in order, transaction processing on the thread does not end immediately as expected when compared to behavior in version 4.0 or version 5.0.
 
Resolving the problem
The behavior observed is the result of a change in the internal design in the way the Transaction Service handles a timeout between WebSphere Application Server v4.0 or v5.0, and v5.1
In v4.0 or v5.0: after the total transaction timeout expired, the transaction was immediately aborted and no exception was raised by the Transaction Service. The next time an attempt was made to talk to a transactional resource, for example, to execute an SQL statement, an exception would be thrown by the resource manager to reflect the fact that the transaction was no longer active. This could then be detected by the application immediately.

In v5.1: when the total transaction timeout time expires, the transaction is marked for rollback, but the transaction is no longer aborted, and no exception is thrown by the Transaction Service. Consequently, all requests to transactional resources involved in the transaction will appear to succeed. However, when the transaction comes to complete, it will never commit, it will rollback instead because it has been marked for rollback.

The Transaction Service itself cannot raise an exception for the application because the timeout detection is done on a different thread to ensure that the timeout is detected at the correct time, and Java™ does not allow one thread to raise an exception on behalf of another thread. Therefore, it is not possible for the bean itself to be told that timeout has happened - the only reliable way is to periodically test if the bean has been rolled back by calling the getRollbackOnly( ) on the beans context or getStatus on the UserTransaction currently active.

The total transaction timeout is usually adjusted until all transactions can finish successfully under normal load, and only unusual circumstances then cause transactions to timeout. In V5.1, since the transaction remains after the timeout time has expired, it does not add any overhead to the overall WebSphere system load to increase the timeout value.

In summary, the total transaction timeout value can be increased so that the timeout does not occur, or a periodic test can be made with the getRollbackOnly() method, so that the timeout can be detected sooner.

 
 
Cross Reference information
Segment Product Component Platform Version Edition
Application Servers WebSphere Application Server for z/OS Not Applicable
Application Servers Runtimes for Java Technology Java SDK
 
 


Document Information


Current web document: swg21207635.html
Product categories: Software > Application Servers > Distributed Application & Web Servers > WebSphere Application Server > Java Transaction Service (JTS)
Operating system(s): z/OS
Software version: 5.1.1.4
Software edition:
Reference #: 1207635
IBM Group: Software Group
Modified date: May 27, 2005