Interface for extracting native JDBC objects from wrapped objects coming from
connection pools. This is necessary to be able to case to native implementations
like OracleConnection or OracleResultSet in application code, for example to
create Blobs or access other vendor-specific features.
Note: Setting a custom NativeJdbcExtractor is just necessary if you want to
cast to database-specific implementations, like OracleConnection/OracleResultSet.
Else, any wrapped JDBC object will be fine.
Note: To be able to support any pool's strategy of native ResultSet wrapping,
it is advisable to get both the native Statement and the native ResultSet
via this extractor. Some pools just allow to unwrap the Statement, some just to
unwrap the ResultSet - the above strategy will cover both. It is typically
not necessary to unwrap the Connection to retrieve a native ResultSet.
When working with a simple connection pool that wraps Connections but not
Statements, a SimpleNativeJdbcExtractor is often sufficient. However, some
pools (like Jakarta's Commons DBCP) wrap all JDBC objects that they
return: Therefore, you need to use a specific NativeJdbcExtractor (like
CommonsDbcpNativeJdbcExtractor) with them.
JdbcTemplate can properly apply a NativeJdbcExtractor if specified, correctly
unwrapping all JDBC objects that it creates. Note that this is just necessary
if you want to cast to native implementations in your data access code.
The Oracle-specific implementation of Spring's LobHandler interface needs
a NativeJdbcExtractor to be able to work on the native OracleConnection.
This is also necessary for other Oracle-specific features that you may want
to leverage in your applications, such as InterMedia.
Note: Setting a custom NativeJdbcExtractor is just necessary if you want to cast to database-specific implementations, like OracleConnection/OracleResultSet. Else, any wrapped JDBC object will be fine.
Note: To be able to support any pool's strategy of native ResultSet wrapping, it is advisable to get both the native Statement and the native ResultSet via this extractor. Some pools just allow to unwrap the Statement, some just to unwrap the ResultSet - the above strategy will cover both. It is typically not necessary to unwrap the Connection to retrieve a native ResultSet.
When working with a simple connection pool that wraps Connections but not Statements, a SimpleNativeJdbcExtractor is often sufficient. However, some pools (like Jakarta's Commons DBCP) wrap all JDBC objects that they return: Therefore, you need to use a specific NativeJdbcExtractor (like CommonsDbcpNativeJdbcExtractor) with them.
JdbcTemplate can properly apply a NativeJdbcExtractor if specified, correctly unwrapping all JDBC objects that it creates. Note that this is just necessary if you want to cast to native implementations in your data access code.
The Oracle-specific implementation of Spring's LobHandler interface needs a NativeJdbcExtractor to be able to work on the native OracleConnection. This is also necessary for other Oracle-specific features that you may want to leverage in your applications, such as InterMedia.