查找[Microsoft][SQLServer 2000 Driver for JDBC]Broken pipe问题所看到的

         今天在自己的测试中发现SQL Server遇到了问题，察看日志，发现JDBC Driver报出了[Microsoft][SQLServer 2000 Driver for JDBC]Broken pipe的问题

         上google查找了以下，国内对于这个问题的说明没有看到，只好来到外文网站，发现老外讨论的挺热乎，在http://www.codecomments.com/发现了自己关心的话题。顺便截取一些信息，供大家参考啦


          

 My java code properly connects to the SQL Server DB via the SQL
Server  2000  JDBC driver.
2 ) During one of our stress tests, we restarted the SQL Server to see
how the code handles it.
3 ) My code doesn ' t really recognize that the SQL server is up and my
calls to DB fail throwing the following exception
(Note: I have tried  this  on Oracle 9i and it works properly. i.e my
code is able to read from Oracle DB on db restart.)

 有一位开发者提问自己的相同java代码在压力测试时，为测试一个场景，重启了SQL Server，导致了上述问题，但是相同操作在Oracle9i中运行良好

I would like to see how you made an oracle jdbc connection that
passed  this  test.
The exception you get is a common one, when the driver finds
that the socket it had been using  for  it ' s connection to the DBMS
is dead during a user call to a JDBC method. You should program
to deal with  this  sort of failure  if  your DBMS may go away sometimes.
Drivers typically  do   * not *  transparently reconnect when a DBMS goes
down and comes back up. Some drivers and DBMSes  do  have failover
capability but  this  is never guaranteed to be transparent because the
context of the connection cannot be guaranteed to be retained across
the failover. Typically  for  a complicated JDBC environment even the
failover drivers require the moral equivalent of making a  new
connection.
Joe Weinstein at BEA

一位来自BEA的开发者分析不同的JDBC驱动不一定会识别数据库重启的过程(后文提到，数据库中也建议不要实现这种识别处理然后恢复原有连接，而是捕获后建立新的连接)，也没有建立新的连接(connection)

Really ?  Then that ' s an unfortunate lack. One thing I like about the
MySQL JDBC drivers is the  " autoReconnect "  feature. If other DBs don ' t
have that, it ' s a big plus for MySQL.

一位来自Mysql的开发者发现这可能是一个很好的feature点(佩服，这样能在问题中发现可能竞争优势的员工确实是所有优秀公司都需要的，不管最后这个需求点是否值得)

I wouldn ' t necessarily put it that way. Think about what happens if you
start a transaction on a connection, then after you  do  some work, the
connection fails; it then auto reconnects, you  do  some more work  while
not knowing anything about what just happened; then you commit your
work, which actually commits only the second half; your DB is now in an
inconsistent state. I think it ' s not worth it.

Alin.

当然，事无完美，马上有人提到这个功能对事务上的可能影响，有的时候，充满激情的头脑，需要有浇冷水的人来，这样才能把问题分析更透彻。

Autoreconnect only works  if  autoReconnect is  true , and even still, you
still get an exception, you just need to re - try  the operation.

However, we ' re planning on deprecating the feature, and requiring
applications to acquire a  new  connection to retry their operation on.

As applications get more - and - more stateful with the way they deal with
JDBC connections and other session state, it ' s the only way to ensure
proper operation.

The real issue is that the original JDBC specification never specified
how  long  a connection should remain alive, so many developers assumed
' forever '   while  most vendors assumed  ' as long as possible ' , which is a
mismatch of expectations, to say the least.

当然，这种讨论总会影响新的思想交锋，撞击出闪亮的火花，我们需要这样的讨论