Oracle JDBC 间歇性连接问题

本文介绍了Oracle JDBC 间歇性连接问题的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我遇到了一个很奇怪的问题这是JDBC连接Oracle数据库的一个非常简单的使用

I am experiencing a very strange problem This is a very simple use of JDBC connecting to an Oracle database

OS: Ubuntu Java Version: 1.5.0_16-b02 1.6.0_17-b04 Database: Oracle 11g Release 11.1.0.6.0

当我使用 jar 文件时OJDBC14.jar 每次都连接到数据库当我使用 jar 文件时OJDBC5.jar 有时会连接，有时会抛出错误(如下所示)如果我用 Java 6 重新编译并使用OJDBC6.jar 我得到与 OJDBC5.jar

When I make use of the jar file OJDBC14.jar it connects to the database everytime When I make use of the jar file OJDBC5.jar it connects some times and other times it throws an error ( shown below) If I recompile with Java 6 and use OJDBC6.jar I get the same results as OJDBC5.jar

我需要 JODB5.jar 中 OJDBC14.jar 中没有的特定功能

I need specific features in JODB5.jar that are not available in OJDBC14.jar

任何想法

错误

> Connecting to oracle java.sql.SQLException: Io exception: Connection reset at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:74) at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:110) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:171) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:227) at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:494) at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:411) at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490) at oracle.jdbc.driver.T4CConnection.<init>(T4CConnection.java:202) at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:33) at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:474) at java.sql.DriverManager.getConnection(DriverManager.java:525) at java.sql.DriverManager.getConnection(DriverManager.java:171) at TestConnect.main(TestConnect.java:13)

代码

下面是我使用的代码

import java.io.*; import java.sql.*; public class TestConnect { public static void main(String[] args) { try { System.out.println("Connecting to oracle"); Connection con=null; Class.forName("oracle.jdbc.driver.OracleDriver"); con=DriverManager.getConnection( "jdbc:oracle:thin:@172.16.48.100:1535:sample", "JOHN", "90009000"); System.out.println("Connected to oracle"); con.close(); System.out.println("Goodbye"); } catch(Exception e) { e.printStackTrace(); } } }

推荐答案

在一些 OTN 论坛 (kr.forums.oracle/forums/thread.jspa?messageID=3699989).但是，没有解释问题的根本原因.以下是我试图解释问题的根本原因.

There is a solution provided to this problem in some of the OTN forums (kr.forums.oracle/forums/thread.jspa?messageID=3699989). But, the root cause of the problem is not explained. Following is my attempt to explain the root cause of the problem.

Oracle JDBC 驱动程序以安全的方式与 Oracle 服务器通信.驱动程序使用 java.security.SecureRandom 类来收集熵以确保通信安全.此类依赖于本机平台支持来收集熵.

The Oracle JDBC drivers communicate with the Oracle server in a secure way. The drivers use the java.security.SecureRandom class to gather entropy for securing the communication. This class relies on the native platform support for gathering the entropy.

熵是操作系统或应用程序收集/生成的随机性，用于密码学或其他需要随机数据的用途.这种随机性通常是从硬件来源收集的，要么来自硬件噪音、音频数据、鼠标移动，要么来自专门提供的随机性发生器.内核收集熵并将其存储为熵池，并通过特殊文件 /dev/random 和 /dev/random 将随机字符数据提供给操作系统进程或应用程序.强>/dev/urandom.

Entropy is the randomness collected/generated by an operating system or application for use in cryptography or other uses that require random data. This randomness is often collected from hardware sources, either from the hardware noises, audio data, mouse movements or specially provided randomness generators. The kernel gathers the entropy and stores it is an entropy pool and makes the random character data available to the operating system processes or applications through the special files /dev/random and /dev/urandom.

从 /dev/random 中读取会消耗所需的比特/字节数量的熵池，从而提供密码操作中通常需要的高度随机性.如果熵池完全耗尽并且没有足够的熵可用，则 /dev/random 上的读取操作将阻塞，直到收集到额外的熵.因此，从 /dev/random 读取的应用程序可能会阻塞一段时间.

Reading from /dev/random drains the entropy pool with requested amount of bits/bytes, providing a high degree of randomness often desired in cryptographic operations. In case, if the entropy pool is completely drained and sufficient entropy is not available, the read operation on /dev/random blocks until additional entropy is gathered. Due to this, applications reading from /dev/random may block for some random period of time.

与上述相反，从 /dev/urandom 读取不会阻塞.从 /dev/urandom 读取也会耗尽熵池，但当熵不足时，它不会阻塞而是重用部分读取的随机数据中的位.据说这容易受到密码分析攻击.这是理论上的可能性，因此不鼓励从 /dev/urandom 读取以收集密码操作中的随机性.

In contrast to the above, reading from the /dev/urandom does not block. Reading from /dev/urandom, too, drains the entropy pool but when short of sufficient entropy, it does not block but reuses the bits from the partially read random data. This is said to be susceptible to cryptanalytical attacks. This is a theorotical possibility and hence it is discouraged to read from /dev/urandom to gather randomness in cryptographic operations.

java.security.SecureRandom 类默认从 /dev/random 文件读取，因此有时会在随机时间段内阻塞.现在，如果读取操作在所需的时间内没有返回，则 Oracle 服务器将客户端(在本例中为 jdbc 驱动程序)超时，并通过从其末端关闭套接字来中断通信.客户端从阻塞调用返回后尝试恢复通信时遇到IO异常.这个问题可能在任何平台上随机发生，尤其是从硬件噪声中收集熵的平台.

The java.security.SecureRandom class, by default, reads from the /dev/random file and hence sometimes blocks for random period of time. Now, if the read operation does not return for a required amount of time, the Oracle server times out the client (the jdbc drivers, in this case) and drops the communication by closing the socket from its end. The client when tries to resume the communication after returning from the blocking call encounters the IO exception. This problem may occur randomly on any platform, especially, where the entropy is gathered from hardware noises.

正如 OTN 论坛中所建议的，此问题的解决方案是覆盖 java.security.SecureRandom 类的默认行为以使用来自 /dev/urandom 的非阻塞读取 而不是从 /dev/random 中阻塞读取.这可以通过将以下系统属性 -Djava.security.egd=file:///dev/urandom 添加到 JVM 来完成.虽然这对于 JDBC 驱动程序等应用程序来说是一个很好的解决方案，但对于执行核心加密操作(如加密密钥生成)的应用程序来说，这是不鼓励的.

As suggested in the OTN forum, the solution to this problem is to override the default behaviour of java.security.SecureRandom class to use the non-blocking read from /dev/urandom instead of the blocking read from /dev/random. This can be done by adding the following system property -Djava.security.egd=file:///dev/urandom to the JVM. Though this is a good solution for the applications like the JDBC drivers, it is discouraged for applications that perform core cryptographic operations like crytographic key generation.

其他解决方案可能是使用可用于平台的不同随机播种器实现，这些实现不依赖于硬件噪声来收集熵.有了这个，您可能仍然需要覆盖 java.security.SecureRandom 的默认行为.

Other solutions could be to use different random seeder implementations available for the platform that do not rely on hardware noises for gathering entropy. With this, you may still require to override the default behaviour of java.security.SecureRandom.

增加 Oracle 服务器端的套接字超时也是一种解决方案，但在尝试此操作之前，应从服务器的角度评估副作用.

Increasing the socket timeout on the Oracle server side can also be a solution but the side effects should be assessed from the server point of view before attempting this.