I was recently struggling with the JDBC connection problem. There was a huge latency i.e. (3-4 minutes) while creating a database connection. Many times, the attempt turned into failure with Connection reset exception. After several hours, it connected one time and froze again.
I have checked several forums and found that this simply means that something in the backend ( at server) decided to stop working due to unavailability of resources etc. It has nothing to do with your code or the number of inserts. There occur some locks after calling SeedGenerator() and SecureRandom().
Reason: The JDBC 11g needs about 40 bytes of secure random numbers, gathered from /dev/random, to encrypt its connect string. /dev/random need very high-quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.
Now the question comes what is an entropy?
Entropy is a technical term for “Randomness”. Computers don’t really generate entropy but gather it by looking at stuff like the variations of hard drive rotation speeds (A physical phenomena that is very hard to predict due to friction etc.) When a computer wants to generate a pseudo random data it will need a mathematical formula with true entropy that it found by measuring mouse clicks, hard drive spin variations etc. Roughly speaking entropy_avail is the measure of bits currently available to be read from /dev/random
It takes time for the computer to read entropy from its environment unless it has cool hardware like a noisy diode or something.
You can check the “filling level” (maybe zero?) of your entropy pool and the overall size of the pool (usually 4096) by issuing
cat /proc/sys/kernel/random/entropy_avail cat /proc/sys/kernel/random/poolsize
Unlike /dev/random, /dev/urandom device will return as many bytes as are requested. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.
Now let’s get back on our JDBC problem. Oracle JDBC 11g seems to use /dev/random by default. So, to overcome such issues of latency use urandom instead of random and do the following configuration in JDK
$JAVA_HOME/jre/lib/security/java.security configuration file, add the line
In the syntax, you need the crazy-looking filename, e.g., the extra,
/./ to trick Java into accepting your filename. If you just use
/dev/urandom, Java decides you didn’t really mean it and replaces what you wrote with
Alternatively, to test a standalone application you can also set this execution parameter at run time instead of setting it in JDK.