继续调查上一篇blog的故障。在websphere的SystemOut里面发现很多WTRN0006W的信息。
[10/24/07 14:59:52:662 EST] 0000000f TimeoutManage I   WTRN0006W: Transaction 0000011056531F8D000000050001C7E40B304AAB611AB4FC574CE136F63A9E07BE78A01B0000011056531F8D000000050001C7E40B304AAB611AB4FC574CE136F63A9E07BE78A01B00000001 has timed out after 120 seconds.
这个日志意味着这个事务在交易生命周期时间（Total transaction lifetime timeout）里面不能提交或者回滚。webspere默认值为120秒。当然WTRN0006W本身不是问题所在，而是一种症状。我们需要找到导致WTRN0006W的原因才能解决问题。
1、poor performance，性能问题。 CPU使用率是否比正常的情况要高？有没有发生swap？是否磁盘空间已满？其他的资源瓶颈？ 你的硬件容量是否满足你的生产系统，建议先解决性能问题再着手调试事务的参数。
2、线程发生等待或者挂起。这种情况SystemOut日志里面WTRN0006W的报错前后会伴随 WSVR0605W 或 WTRN0041I的报错。
3、JVM 有错误、不健康。例如：发生OutOfMemory，当发生heapdump的时候，所有线程都会挂起直到heapdump完成，所以造成事务超时。
4、目标服务不可用。如果事务需要异步SCA调用，当目标服务不可用的时候也会造成事务超时。   当异步SCA调用不能保证稳定的返回时间，应该设置异步SCA调用的timeout。因为修改事务级别的timeout是对整个应用服务器生效，影响比较大。   确保JDBC连接池的连接数和JMS连接池和会话池配置合适。
5、打开事务的traces文件，让问题重现的时候可以分析。注意：设置traces文件的数量和大小。   通过Transaction ID定位到处理这个事务的线程，然后跟踪线程的状态调查事务超时的原因。
6、确实事务需要处理好久，需要增大Total transaction lifetime timeout的设置。