Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop NativeJdbcExtractor mechanism in favor of java.sql.Connection.unwrap() [SPR-14670] #19234

spring-projects-issues opened this issue Sep 5, 2016 · 4 comments
in: data Issues in data modules (jdbc, orm, oxm, tx) type: task A general task


Copy link

spring-projects-issues commented Sep 5, 2016

John Smith opened SPR-14670 and commented

Spring's NativeJdbcExtractor predates JDBC 4.0 and therefore Connection#unwrap. With JDBC 4 pools and drivers being reliably available now, there is no need to keep a separate mechanism around.

Reference URL: #1090

Issue Links:

Referenced from: commits 427fd9b, 07dd61e

Copy link
Collaborator Author

spring-projects-issues commented Feb 15, 2017

Juergen Hoeller commented

Since we're raising the baseline to Java 8 for Spring 5 anyway, we tend to drop outdated mechanisms such as NativeJdbcExtractor completely. After all, on JDK 8+, there is no excuse for a pre-JDBC-4.0 driver or pool anymore, so Connection.unwrap is reliably available.

On 4.3.x - where we're still supporting WebSphere 7 and Oracle 9i JDBC drivers - it's hard to formally deprecate the mechanism. And in 5.0, keeping it around in deprecated form seems unnecessary. So we're simply going to drop it completely as of 5.0 M5.

Copy link
Collaborator Author

spring-projects-issues commented Sep 28, 2017

David Goblirsch commented

This is just FYI. I understand that this issue is closed and that NativeJdbcExtractor is no longer required, but I just wanted to let you know that Connection.wrap() is much less efficient.

I created a pool using Apache Commons DBCP 2 for Oracle 12.1 using the oracle driver. Using Spring 4.3, I had an automated JUnit test suite with 5 tests that used OracleJdbc4NativeJdbcExtractor to extract OracleConnection, OracleStatement, and OraclePreparedStatement from the Connections returned from this pool, and from Statements and PreparedStatements built from those connections. The tests are very simple. For example, get a Connection from the pool, assert it is not an OracleConnection, apply nativeJdbcExtractor.getNativeConnection, assert the result is an OracleConnection. Similarly structured tests for Statement and PreparedStatement, and for the connections obtained from those.

(I am sorry but I cannot provide the actual test code.)

Running the tests on JDK 1.7 or JDK 1.8, for OracleJdbc4NativeJdbcExtractor, the 5 tests complete in 430 msec on average.

On Java 7, for java.sql.unwrap, the 5 tests complete in 2410 msec on average, almost 6x longer.

On Java 8, for java.sql.unwrap, the 5 tests complete in 1990 msec on average, almost 5x longer.

Looks like I might need to extract the NativeJdbcExtractor classes into a little utility library to keep around for some applications when I move them to Spring 5; your code is much more efficient than the JDK implementation. Not tested with 9 yet.

Copy link
Collaborator Author

spring-projects-issues commented May 15, 2018

PavelStepanek commented

Hi - I have hit some issues as a result of this JIRA, can someone take a look here and help to clarify what is wrong?

Copy link

nandeeshnaik commented Jul 24, 2020

Please pardon me for commenting on a closed thread.
I have an issue in Springboot migration from 1.5.9 to 2.3.1 related to JdbcTemplates's NativeJdbcExtractor.

I have linked the StackOverflow Question,

It's basically related to dynamic update of JdbcTemplate's schema based on the REST call.

Is it even possible on Springboot2?
Should I get rid of JdbcTemplate? (Need lot of coding and testing effort)
Should I stop migrating?

Please help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: data Issues in data modules (jdbc, orm, oxm, tx) type: task A general task
None yet

No branches or pull requests

3 participants