If transactions fail for this reason, then the client receives such messages as JTA Transaction Aborted. If you see this message on the client or transactions fail, but you have not determined why, then you may want to increase this value. If you prefer long waits to failures, then it is worth it to try a large increase such as adding a zero (multiplying by 10).
Transaction inactivity time out
This is another WebSphere timing parameter that can stop a long running transaction. The default is 60000, which seems large. But unlike the other timers, it is measured in milliseconds and is, therefore, only one minute. You may want to increase this for similar reasons as the previous setting.
Figure 5-24 shows Transaction time out and Transaction inactivity time out parameters in the top half of the Advanced page of the Application Server panel.
Figure 5-24 Advanced page of the Application Server panel
Ping interval and timeout
The administrative server pings your application regularly to check whether it is still operating. If it fails, then it is ended and restarted. The ping interval controls how often this is performed. The ping timeout controls how long the administrative server waits before it assumes failure. The ping initial timeout is similar to ping timeout except that it covers the initial ping after the application is started. It is usual to use a larger value for the initial time out.
If performance is poor, then increase all of these parameters to avoid a slow application being mistaken for a failed application. If your application server is periodically ended and restarted, then this may explain the poor performance. A “SIGKILL received” message in the job log would be normal in this case.
When performance is poor, consider simply adding a zero to the timeout values. Note that the time out values are most important. However, there is no point in frequent pings if the time out is large. Therefore, increase the ping interval as well.
