SQLServer 2000 Driver for JDBC]Broken pipe
今天在自己的测试中发现SQL Server遇到了问题，察看日志，发现JDBC Driver报出了[Microsoft][SQLServer 2000 Driver for JDBC]Broken pipe的问题
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.)
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
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.
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.
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.