Last updated on MARCH 07, 2017
Applies to:JDBC - Version 188.8.131.52.0 and later
Information in this document applies to any platform.
On : 184.108.40.206.0 version, Thin JDBC driver
Normally, when creating the first JDBC connection within the JVM, the JDBC driver itself creates a thread called "oracle.jdbc.driver.BlockSource.ThreadedCachingBlockSource.BlockReleaser". This happens automatically in PhysicalConnection.setBlockSource, which is called whenever a JDBC Connection is created.
The BlockSource is always created with BlockSource.Implementation.THREADED which leads to an instantiation of the class ThreadedCachingBlockSource which then creates the BlockReleaserListener. This behaviour can be overridden with the connection property "oracle.jdbc.useThreadLocalBufferCache" set to "true". With this property enabled, no BlockReleaser thread is created when opening a new JDBC connection.
Up to this point, the JDBC driver is working as intended. However, the very moment createStatement() is called on the connection, the BlockReleaser thread will still be created despite the fact that "oracle.jdbc.useThreadLocalBufferCache" is set to "true".
When using "ThreadedCachingBlockSource" (which is the default) the ThreadedCachingBlockSource is manipulating some JVM internal JVM beans upon instantiation, changing sensitive values for the whole JVM (see Stacktrace) which is causing bad side effects.
In this stack it is seen that BlockSource$ThreadedCachingBlockSource is created which also creates BlockReleaser thread.
Application is constantly crashing when BlockSource$ThreadedCachingBlockSource is instantiated and BlockReleaser thread is running. There is no way to prevent the instantiation of BlockSource$ThreadedCachingBlockSource.
Manipulating these beans should be forbidden, but it is done (through a SecurityManager), and the JDBC driver stops working. When the beans are manipulated this way, the application is constantly crashing.
This behaviour is seen in the latest odbc7.jar including the latest <Patch: 18707079>.
Instantiation of ThreadedCachingBlockSource is expected to be prevented and therefore prevent the manipulation of the beans.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
Million Knowledge Articles and hundreds of Community platforms