informix的错误

两个进程，一个进行大事务操作，一个进行快速的小事务。（采用ESQL/C开发）  
  它们访问同样的表，这些表的锁模式是行级锁。  
  可以保证这两个事务涉及的记录是不同的，  
  现在的问题是，先运行大事务操作后，再运行小事务操作，就出现错误：  
  Could   not   do   a   physical-order   read   to   fetch   next   row  
  我以前ORACLE上开发的时候，没有发现这样的问题，但是到INFORMIX后，就出现这样的问题  
  我试过几种ISOLATION的组合，都无法避免这个问题  
  不知有那位INFORMIX的高手知道这个问题的解决方法，请告诉小弟  
  先谢过了

我写了两个测试程序，不存在你说的问题，两个程序都能完成修改。  
  alter   table   tab   lock   mode   (row   )

你试试这个：  
  create   table   t1  
  (  
          c1     char(10)   not   null,  
          c2     int             not   null  
  )   lock   mode   row;  
   
  insert   into   t1   values   ('a',   1);  
  insert   into   t1   values   ('b',   2);  
  insert   into   t1   values   ('c',   3);  
   
  事务1:  
  begin   work;  
  update   t1   set   c2   =   0   where   c1   =   'a';  
   
  先不提交，在另一个ISQL中执行  
  事务2：  
  begin   work;  
  update   t1   set   c2   =   0   where   c1   =   'b';  
   
  这样就出错了

我测试了，给表加了个索引就可以了。  
  create   unique   index   t1_idx1   on   t1(   c1   );  
  update   statistics   for   table   t1;  
 

 

使用Informix时出现的异常："could not do a physical order read to fetch next row"，具体表现在大数据量操作数据库的时候，容易出现。在JavaYou找到解决问题所在:
嗯，我试了  
  确实是这样  
  那看来row   lock跟索引有关系啊

一方面可以在隔离级别的选择上进行改动（但并不彻底），另一方面则是因为Informix默认锁等待时间为0，即在操作（update、delete等）数据库的时候，如遇到其他操作也在使用同一张表的情况时，则不等待和返回异常。

最简单的解决方法就是每次在获取新的（注意是新的，原有的连接也无妨，但影响效率）数据库连接时，首先执行设置连接的锁等待时间的Sql：

SET LOCK MODE TO WAIT 10 （意思是设置锁等待时间为10ms），

这样基本解决问题，不再出现异常情况。

具体错误解释：   #finderr -244
 原因：a.锁表b.记录太多c.页损坏d.某个进程死了以后资源未释放导致  
在数据库端用 onstat –g ses/onstat –g sql /Onstat –k 等找出锁表进程，用onmode –z结束该进程，不行，重启数据库释放。
锁方式：   行方式（row），页方式（默认page），表方式(table)。
 解决：   1．降低锁级别   2．减少加锁事务的时间跨度   3．设置等待解琐时间 相关命令：   ）
检查索引及页损坏情况#oncheck –cID database_name:table_name   )
 查看锁级别#oncheck –pt database_name:table_name   )
设置锁级别（行方式）#alter table table_name lock mode(row)   )
设置隔离级别#set isolation to dirty read   )
设置等待解锁时间（不宜过大）#set lock mode to wait second
(秒)不等待#set lock mode to not wait

经常出现的Connection reset by peer: 原因可能是多方面的，不过更常见的原因是：
①：服务器的并发连接数超过了其承载量，服务器会将其中一些连接Down掉；
②：客户关掉了浏览器，而服务器还在给客户端发送数据；
③：浏览器端按了Stop；

 Connection reset by peer: socket write error
 error: java.net.SocketException: Broken pipe

Weblogic "java.net.SocketException: Broken pipe" Error
     今天碰到一个错误＂java.net.SocketException: Broken pipe＂.(写了个脚本可以支持隐藏/显示，msn因为安全原因把我的脚本给删除了．只好把整个错误显示在下面)
　　java.net.SocketException: Broken pipe
　　　at java.net.SocketOutputStream.socketWrite0(Native Method)
　　　at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
　　　at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
　　　at weblogic.servlet.internal.ChunkUtils.writeChunkNoTransfer(ChunkUtils.java:280)
　　　at weblogic.servlet.internal.ChunkUtils.writeChunks(ChunkUtils.java:241)
　　　at weblogic.servlet.internal.ChunkOutput.flush(ChunkOutput.java:311)
　　　at weblogic.servlet.internal.ChunkOutput.checkForFlush(ChunkOutput.java:387)
　　　at weblogic.servlet.internal.ChunkOutput.write(ChunkOutput.java:254)
　　　at weblogic.servlet.internal.MultibyteOutput.write(ChunkOutput.java:482)
　　　at weblogic.servlet.internal.ChunkOutputWrapper.write(ChunkOutputWrapper.java:125)
　　　at weblogic.servlet.internal.ServletOutputStreamImpl.write(ServletOutputStreamImpl.java:184)
　　　at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:66)
　　　at java.io.BufferedOutputStream.write(BufferedOutputStream.java:110)
　　　at java.io.FilterOutputStream.write(FilterOutputStream.java:80)
出错场景：Weblogic 服务器上同时跑着三个Web Application　A,B,C.　控制台上每次A的某个数据库连接完了就导致B application的客户端死掉．
     错误分析：A application出错导致整个Weblogic的错误而引起B application的错误．而之前单独跑两个程序时都没有出现过问题，也就是说问题不是出现在Application A or B里面．
 
     总结：A应用使用了数据库连接池，每次应用重起（restart）的时候都会建立一个连接池，这些连接被应用服务器保存在ServletContext中,而这个时候数据库重起了，导致ServletContext中的connection失效，然后再有请求使用该connection的时候，就会报上面的错误．
 
一般是客户端在连接还没有完全建立的时候就取消连接，比如用户按了浏览器上面的“停止”按钮，一般来说没有什么问题
     所以，在这种情况下，当数据库或数据服务重起以后，应用服务起也需要重新启动，让connection全部更新．

无非是管道的另一端没有为读而打开，这样你在写入管道时，会导致管道破裂。
也许是自己的客户端写数据的时候，你的服务端已经把这个连接关闭了
初始化时加上signal(sigpipe,   sig_ign);

  昨天有个程序除了问题，调试的时候发现是在SOCKET通信的时候对方关闭连接的情况下出现broken pipe错误。在网上搜索了一番，别人解释原因是向已经关闭连接的SOCKET管道写入数据造成的，但是我的程序只是在对方关闭的时候继续RECV，难道RECV也会向管道写入数据，这个问题以后再研究吧。

    知道了问题就好办了。UNIX的系统是采用信号机制向进程通知这种系统错误的，13 SIGPIPE 的默认操作是Exit，所以在程序里面写一个自己的信号处理函数，不让进程退出就OK。不过值得注意的是在截获一次信号以后，系统会把信号处理又恢复到默认状态，所以需要再次设置。另外，对于多线程，我是在主线程里面做的信号处理，其他线程没有做，但是我理解信号是发给进程的，所以应该只要有一个线程处理了信号就可以。

源码：

void InitSignal(void);
void handle_signal(int s) ;

/*初始化时及每次处理完时调用*/
void InitSignal(void)
{
 signal(SIGPIPE,handle_signal);
}
/*信号处理函数*/
void handle_signal(int s)
{
 InitSignal();
}

Broken pipe产生的原因通常是当管道读端没有在读，而管道的写端继续有线程在写，就会造成管道中断。（由于管道是单向通信的） SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址，没有物理内存对应该地址。 以下是UNIX的信号解释： 11 / SIGSEGV: Unerlaubter Zugriff auf Hauptspeicher (Adressfehler). 12 / SIGUSER2: User-defined Signal 2 (POSIX). 把_JAVA_SR_SIGNUM改成12只是将信号至成user-defined，让它不报出来而已，不能解决问题。 建议采取的方式：

1． 资源没有完全释放，用完后要至NULL 值（JAVA的GC没那么完善）

2． 数据库连接顺序关闭！（RS，PS，CONN）

3． 优化JAVA虚拟机 加入相应的内存参数！

4． 不要在数据库中获取大段文本（即一个栏位的值不要太大）

5． JAVA 不推荐 用String 获取大量信息。（容易造成内存泄露，建议用StringBuffer）

6． 页面重复提交

7． 尽量将METHOD移到JAVA中，在JSP中所有的方法都看做全局变量，编译执行本身就有很多问题。

引起java.net.SocketException:Broken pipe这个异常的原因是你使用了多个线程同时对一个Socket通道进行读/写（windows环境没有这个问题），简单的说就是Unix/Linux下不能同时对一个Socket通道进行读和写。并且我也尝试过使用同步控制来防止对同一个Socket通道进行读和写，不过只是降低了该异常的发生概率（绝对不是同步控制有问题），发送和接收加入一段延迟后不会发生该问题，当然应用是不能容忍这样的处理效率和性能的。
最后我把整个网络通信改成用new io的非阻塞模式，在单线程中处理多路通道，没有这个问题，而且似乎系统吞吐量比先前更高了，不过唯一剩下一个问题，至今仍未解决！
详见我的问题贴：

8． 尽量用较新较稳定版本的JDK，低版本的JVM本身也有很多BUG，比如1。5的垃圾回收比起1。2，1。3一定是非常明显的进步。

9． LINUX系统本身没有这么稳定，有些问题无法避免的~~：）

--------------------------------------------------------------------------------

主题: 答复:  error（关于Broken pipe ，connection reset的问题） Broken pipe ，connection reset的问题在report里出现得比较频繁，具体原因不明。 请大家帮忙看看，有什么好的解决方案 关于服务器出现broken pipe ，connection reset的问题，在网上找到一些说法： 1、 服务器出现broken pipe ，connection reset解决方法 　 linux下webloigc经常出现broken pipe，socket....connection reset错误. 有有可能是linux的线程机制会产生JVM出错的问题，特别是在连接高峰期间经常出现这样的问题，tomcat在linux下也出现类似情况。 解决办法是在环境变量中设置： _JAVA_SR_SIGNUM = 12 基本就可以解决。 sun的解释：－－posted by: cooper Below is a clipping from Sun on working around JVM crashes under high thread counts in the JVM 1.3 for Linux On Linux, use a larger signal number for hotspot thread suspension/resumption handler. The signal number being used is specified by environment variable _JAVA_SR_SIGNUM. Setting it to a number larger than SIGSEGV (11) will solve the problem. A good number to use is 12, which is SIGUSR2. Using signal 16 to work around the problem might have potential problems. So on tcsh, "setenv _JAVA_SR_SIGNUM 12" can solve the problem. 原文：http://server.jz173.com/20050610/20050610140726.html 2、 Broken Pipe是网络资源不足的情况出现的会发送SIGPIPE信号，LINUX下默认程序退出的只要忽略此信号即可 signal(SIGPIPE,prog_no_Stop); 原文：http://www.coolunix.com/messages/230931.html