【IT168 技术文章】
WAS系统垮了，客户疯了，又有事情做了！！！
分析了日志文件
Native_stderr.log
Native_stdiut.log
Server1.pid
Startserver.log
Stopserver.log
Systemerr.log
Systemout.log
PS: 由于对log文件的收集没有加 -trace参数，所以得到的信息比较有限，希望以后兄弟们能够提交日志文件的时候能够记得加这个参数。
虽然比较有限，但是还是可以看到一些端倪：
通过分析SystemOut.log日志文件，可以得出以下信息：
************ Start Display Current Environment ************
WebSphere Platform 5.0 [BASE 5.0.1 ptf1M0313.03] running with process name oasvr\oasvr\server1 and process id 4460
Host Operating System is Windows 2000, version 5.0
Java version = J2RE 1.3.1 IBM Windows 32 build cn131-20030329 (JIT enabled: jitc), Java Compiler = jitc, Java VM name = Classic VM
was.install.root = d:\ibm\WebSphere\AppServer
user.install.root = d:\ibm\WebSphere\AppServer
Java Home = d:\ibm\WebSphere\AppServer\java\jre
ws.ext.dirs = d:\ibm\WebSphere\AppServer\java/lib;d:\ibm\WebSphere\AppServer/classes;d:\ibm\WebSphere\AppServer/classes;d:\ibm\WebSphere\AppServer/lib;d:\ibm\WebSphere\AppServer/lib/ext;d:\ibm\WebSphere\AppServer/web/help;d:\ibm\WebSphere\AppServer/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime
Classpath = d:\ibm\WebSphere\AppServer/properties;d:\ibm\WebSphere\AppServer/properties;d:\ibm\WebSphere\AppServer/lib/bootstrap.jar;d:\ibm\WebSphere\AppServer/lib/j2ee.jar;d:\ibm\WebSphere\AppServer/lib/lmproxy.jar
Java Library path = d:\ibm\WebSphere\AppServer\java\bin;.;C:\WINNT\system32;C:\WINNT;d:\ibm\WebSphere\AppServer\bin;d:\ibm\WebSphere\AppServer\java\bin;d:\ibm\WebSphere\AppServer\java\jre\bin;D:\ibm\WebSphere MQ\Java\lib;d:\oracle\ora92\bin;C:\Program Files\Oracle\jre\1.3.1\bin;C:\Program Files\Oracle\jre\1.1.8\bin;D:\j2sdk1.4.2_09\bin;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;D:\ibm\WebSphere MQ\bin;D:\ibm\WebSphere MQ\WEMPS\bin;C:\Program Files\IDM Computer Solutions\UltraEdit-32;D:\ibm\WebSphere MQ\bin;D:\ibm\WebSphere MQ\java\bin;D:/ibm/WebSphere MQ/WEMPS\bin
WebSphere Application Server Base Version 5.0.1,平台版本0313.03，
该版本对应JDK:1.3.1.07(SR4)
OASVR可以推测其运行环境是一个J2EE的OA平台,just in time 已经打开
系统环境变量中使用了WebSphere MQ,根据路径可以判断不是WAS自带message,因此对应MQ版本应该为CSD07，从路径中可以看到使用了2个Oracle9iR2实例，一个对应的JRE:1.1.8;一个对应的JRE：1.3.1.应用部署是在jdk1.4.2.09。
另外报错误：
[07-4-19 9:56:33:328 CST]
6130d48d SessionFactor W net.sf.hibernate.impl.SessionFactoryObjectFactory Could not bind factory to JNDI
[07-4-19 9:56:33:344 CST]
6130d48d SessionFactor W net.sf.hibernate.impl.SessionFactoryObjectFactory TRAS0014I: 下列异常已记录 javax.naming.OperationNotSupportedException: The operation on the context "java:env" cannot be completed. All contexts under java:comp/env are environment contexts and are read-only.
[07-4-19 9:56:34:422 CST]
6130d48d SharedPool I J2CA0086W: 在本地事务包含边界中使用的资源 jdbc/ylrun 的可分享连接
[07-4-19 9:56:34:906 CST]
6130d48d WSRdbDataSour u Database version is Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.7.0 - Production
[07-4-19 9:56:34:906 CST] 6130d48d
WSRdbDataSour u JDBC Driver version is 9.2.0.1.0
信息：WAS数据源版本：Oracle 9.2.0.7.0 64bit
采用了数据挖掘组件，其中Jserver版本9.2.0.7.0
JDBC驱动9.2.0.1.0（目前看不到是type2还是type4驱动）
错误：不能绑定JNDI
解决办法：
可以通过log看到应用中使用了hibernate数据持久化技术、结合Startserver.log、Stopserver.log、Systemerr.log、Systemout.log此错误是配置文件的问题，如果hibernate配置文件有session_factory_name这个变量，<session-factory name="foo"> 会试图将一个SessionFactory实例以foo为名bind到jndi上，而有的application container不支持jndi绑定。把这个变量去掉即可。把引用代码也要修改：
大致改成这样：
SessionFactory sf = new Configuration().configure()
.buildSessionFactory();
Session session = sf.openSession();
Transaction tx = session.beginTransaction();
WAS确实可以不需要自己写程序来进行绑定，也可以由Hibernate自己在运行期进行动态绑定。但是如果使用Hibernate自己的运行期绑定的话，有一个悖论，就是只有在Hibernate被初次调用进行初始化的时候，才会将SessionFactory的实例绑定到JNDI上去，那么意味着，在首次调用Hibernate之前，JNDI上是没有SessionFactory实例的，所以你必须在所有的其它程序通过JNDI获得SessionFactory实例之前，运行某个程序对Hibernate进行初始化，把SessionFactory实例绑定到JNDI上。如果是纯Servlet/JSP应用的话，可以配置一个load-up=1的servlet进行Hibernate的初始化，如果是混合EJB，Servlet/JSP的应用，就无法保证在程序被调用前对Hibernate进行初始化，因此对于WebSphere来说，最保险的解决办法就是建立一个StartUp类，确保WAS一启动，就对Hibernate进行初始化。
错误：java:env命名异常，报错误TRAS0014Ijava.lang.ClassNotFoundException: cn.com.info21.power.runlog.action.TestAction
解决办法：
查看class情况，该错误可能由以上错误引起。
分析日志system.out_07.04.19_09.51.59.log
[07-4-19 9:29:49:422 CST]
7ac9d17d Helpers W NMSV0610I:
从 javax.naming.Context 实现中抛出 NamingException。详细信息如下：
上下文实现：com.ibm.ws.naming.java.javaURLContext
上下文方法：createSubcontext(String)
上下文名称：java:comp/env
目标名称：hibernate
其它数据：
异常堆栈跟踪：javax.naming.OperationNotSupportedException: The operation on the context "java:env" cannot be completed
错误NMSV0610I
依然是env的原因，如果报该错误号，但上下文com.ibm.ws.naming.jndicos.CNContextImpl 的话，那么需要注意J2C问题了。一般这样的问题是应用是EJB 1.1规范进行开发的，而部署到WAS5上面的时候，连接遵从J2C的数据源就会出现这样的错误，解决办法看我以前写的一个EJB移植问题文档。
[07-4-18 9:19:57:031 CST] 1f7a20d0 SystemErr R java.net.SocketException: Connection reset by peer: socket closed
[07-4-19 9:32:23:328 CST] 7e02d14f WebGroup E SRVE0026E: ［Servlet 错误］－［Connection reset by peer: socket write error］：java.net.SocketException: Connection reset by peer: socket write error
错误：SRVE0026E，servlet错误，Socket写入错误
类似这种错误，我以前解决了一个更加怪异的。WAS5+SQLSERVER2000SP4采用ODBC数据源连接时，不出现这种错误，而采用JDBC则出现这种错误.解决办法：不使用SP4,使用SQL SERVER SP3A即可解决。
SRVE0026E错误，请升级WAS补丁到5.1即可解决数据库访问并发释放连接、socket写入错误等问题
错误：在本地事务边界中使用资源连接分享，报错误J2CA0086W
解决办法：
系统报告“J2CA0086W”是为了警告用户，应用程序正在一个本地交易（而不是全局交易）中使用共享连结，例如按照如下的方式使用了数据库的连接：
get con1; //建立一个新的连接con1
use con1; //使用con1
get con2; // 一个新的连接con2被建立。
// 再此处我们不能使用con1，因为它还没有被关闭
use con2;
close con1;
close con2;
解决这个问题的方法是打补丁PQ80044，打完这个补丁以后，“J2CA0086W”的警告将不会对于每一次连接都在日志中产生，而是对于每一个连接池产生一次。这个补丁已经被添加到WAS fix 5.0.2.3中，所以，也可以通过打补丁包WAS fix 5.0.2.3解决该问题。
注释：我的思路：
1、 由于配置的是Oracle JDBC Thin Driver,所以只能开一个连接,启动一个事务,关闭事务.但是由于应用中统计等功能比较多,出现打开一个连接,启动一个事务,又打开一个连接(报错),关闭事务的情况,所以想把JDBC改成Oracle JDBC Thin Driver (XA)可以实现打开一个连接,启动事务,又打开一个连接,启动事务,关闭事务,关闭事务的机制.
2、 WAS5默认是2步事务提交、也就是在insert以后需要COMMIT才能提交
3、 还有就是在组装时,注意下要配置资源引用(名称jdbc/cceaoa3ds类型javax.sql.DataSource认证container,IBM扩展中的隔离级别:可提交事务读).Oracle JDBC Thin Driver (XA) 是用作分布式事务的，对于这个CASE，由于都部署在一台机器上，用Oracle JDBC Thin Driver 即可
4、 websphere 5.x 对事物管理有个 bug，如果用 struts 需要在 action 与 jsp 之间 close transaction.
