Understanding JDBC Drivers

You can have an understanding on JDBC Drivers through the information provided in section here. Further, you can also view about the installation and things to take care while installing the JDBC Drivers.

In order for the JDBC Connector to access a relational database, it needs to access a driver, a set of subroutines or methods contained in a Java™ classlibrary. This library must be present in the CLASSPATH of IBM Security Directory Integrator, otherwise IBM Security Directory Integrator will not be able to load the library when initializing the Connector, and hence be unable to talk to the Relational Database (RDBMS). A good way to install a JDBC driver library such that IBM Security Directory Integrator can use it is to copy it into the TDI_install_dir/jars directory, or a directory of your choosing subordinate to this, for example TDI_install_dir/jars/local.

Note:

Some drivers may contain native code, typically presented in .dll or .so files – these need to be added to the PATH variable in order for IBM Security Directory Integrator to pick them up at run time.
Be aware of duplicate class names. If your libraries contain classes that duplicate classes in any of the other libraries in the CLASSPATH, it is undefined which class will be loaded.
The library should be readable by all users.
The applications wanting to use the library must be restarted after installing the library (Configuration Editor, IBM Security Directory Integrator Servers.)

There are 4 fundamental ways of accessing an RDBMS through JDBC (these are often referred to as driver types):

Drivers that implement the JDBC API as a mapping to another data access API, such as Open Database Connectivity (ODBC). Drivers of this type are generally dependent on a native library, which limits their portability. The JDBC-ODBC Bridge driver is an example of a Type 1 driver; this driver is generally part of the JVM, so it does not need to be specified separately on the IBM Security Directory Integrator classpath.
To configure ODBC, see Specifying ODBC database paths.

Note: The JDBC-ODBC bridge may be present in any of the different platform-dependent JVM's that IBM® ships with the product. However, IBM supports the JDBC-ODBC bridge on Windows platforms only. In addition, performance is likely to be sub-optimal compared to a dedicated, native ("Type 4") driver. Commercial ODBC/JDBC bridges are available. If you need an JDBC-ODBC bridge, consider purchasing a commercially available bridge; see also the JDBC-ODBC bridge drivers discussion at http://java.sun.com/products/jdbc/driverdesc.html.
Drivers that are written partly in the Java programming language and partly in native code. The drivers use a native client library specific to the data source to which they connect. Again, because of the native code, their portability is limited.
Drivers that use a pure Java client and communicate with a middleware server using a database-independent protocol. The middleware server then communicates the client's requests to the data source.
Drivers that are pure Java and implement the network protocol for a specific data source. The client connects directly to the data source.

With the exception of the JDBC-ODBC bridge on Windows, we only use Type 4 drivers with IBM Security Directory Integrator. We will discuss other types as well—in the context of each of the supported databases—for a better understanding.

JDBC Type 3 and Type 4 drivers use a network protocol to communicate to their back-ends. This usually implies a TCP/IP connection; this will either be a straight TCP/IP socket, but if the driver supports it, it can be a Secure Socket Layer (SSL) connection.

Note: When working with custom prepared statements, make sure that the JDBC used driver is compliant with JDBC 3.0. There is a known issue with IBM solidDB® 6.5, since the driver implements only JDBC 2.0. If the Use custom SQL prepared statements option is enabled when working with this database, a java.lang.NullPointerException will be thrown.